Managing Resources

All requests for GVP services go through the Resource Manager, which identifies a SIP resource that is capable of serving the request, and forwards the request to it. The Resource Manager monitors GVP resources to maintain an up-to-date status of the resources used in the GVP deployment. The Resource Manager also manages GVP resources to provide load balancing and, if applicable, high availability for each resource type.

The following subsections provide more detailed information about how the Resource Manager performs its resource-management functions.

Resource Groups

The Resource Manager receives resource information from Genesys Management Framework. Logical resource objects in Management Framework represent groupings of resources that share common properties, such as service type (for example, voicexml), capabilities (for example, support for a specific VoiceXML grammar), and method of load balancing (for example, round robin).

Resources are grouped by the following service types:

Recording Server
voicexml
ccxml
msml
conference
gateway
cti
recordingclient
recordingserver

Resource service types in the Media Control Platform group are:

announcement
conference
CPD
Media
msml
recordingclient
voicexml

For detailed information about all the resource group properties, see the descriptions of the logical group configuration options in the section about configuring Resource groups in the GVP 8.5 User's Guide.

Management Framework gives the Resource Manager a list of logical resource objects and a list of physical resources. Each physical resource belongs to a logical resource.

Resource Groups:

Media Control Platform (MCP)
Call Control Platform (CCP)
Gateway
CTI Connector (CTIC)

Resource Groups in HMT Environments

Starting in GVP 8.1.2, Resource Groups are part of a Configuration Unit (CU), with each CU created under a specific tenant. CUs contain a gvp.resources section that includes a rm_dbid configuration option that point to DBIDs for specific Resource Manager instances. If this option is not defined, the CU is considered unassigned and not in use.

The following sections describe the way in which the Resource Manager handles CUs and manages the Resource and DID Groups within them:

Handling of CUs

When the Resource Manager (RM) searches the tenant hierarchy, it parses only those GVP CUs which have the same DBID that the RM has, configured in the rm_dbid option. The resources that are contained in the CU service both the parent tenant and all of the child tenants in the hierarchy. Child tenants are identified by the value of the tenant.N configuration option, where N=<number> (for example, tenant.1, tenant.2, and so on) is the value of the DBID of the child tenant. If there are no configured tenant.N options in the CU, the Resource Manager assigns the resources that are contained in the CU to all of the child tenants in the entire sub tree for the hierarchy. The Resource Manager manages CUs in the following additional ways:
- When it checks the tenant.N option, if the Resource Manager finds that the DBID does not match any of the child tenants in the hierarchy, it ignores that configuration.
- A single Resource Manager instance can handle the assignment of more than one CU under a specific tenant. In this case, the Resource Manager handles all of the CUs for that tenant and all of the resources that are contained in the CUs.
- When the Resource Manager is configured for HA, a single CU can be assigned to more than one Resource Manager instance, because, when Resource Manager is clustered, the two instances must manage the same set of resources.
- The Resource Manager uses a top-down method to assign resources; therefore, although child tenants are serviced by resources that are assigned to the tenant, resources that are assigned to the child cannot service requests for the parent tenant of that child.

Resource Group Management

The Resource Manager determines if Resource Groups are contained in a CU by checking the gvp.lrg option under the Annex section. In HMT environments support these types of Resource Groups:
- Media Control Platform groups
- Call Control Platform groups
- CTI Connector groups
- Gateway groups
- Recording Server groups

Gateway Resource Groups continue to conform to the Resource Group architecture in GVP 8.1.1 and earlier 8.x releases, and the address of record (AOR) and port count are configured in the same way.

Resource Configuration

The Media Control Platform, Call Control Platform, and CTI Connector Applications have a gvp.rm section, which includes the following configuration options:
- aor--Address of record
- port-capacity--Number of ports that are allocated for this resource
- redundancy-type--Monitoring status of the resource (active or passive)

DID Group Validation

The Resource Manager validates the DID Group and DN assignments for all tenants.

Monitoring Status

The Resource Manager acts as a SIP registrar (Request for Comments [RFC] 3261) for resources about which it receives information from Management Framework. The Resource Manager maintains information about the registration and usage status of each resource. If the logical resource group has been configured for monitoring (in the monitor-method configuration option), the Resource Manager also monitors resource health. Health monitoring performed by the Resource Manager is separate from Simple Network Management Protocol (SNMP) management (see SNMP Monitoring).

Configuration options in the registrar and monitor configuration sections for the Resource Manager Application object enable you to control the monitoring behavior of the Resource Manager.

Notification of Resource Status

When Resource Manager is deployed as part of the VPS solution in a multi-tenant environment, it provides port-availability notifications that include data which is specific to each tenant.

SIP Server generates a SUBSCRIBE request that includes an X-genesys-mediaserver-status event and the Resource Manager immediately sends a NOTIFY response, which includes the current status of all Media Control Platforms in the deployment, whether in-service or out-of-service, and it continues to send notification if the status of any one of the Media Control Platform changes.

Each entry in the body of the NOTIFY message is in the following format, <Tenant-Name>/<MCP-IP:Port>/<MCP-Status>, where <Tenant-Name> is the name of the tenant that was specified in the SUBCSCRIBE request and <MCP-Status> is either in-service or out-of-service. See the following example of a NOTIFY message:

NOTIFY sip:Environment@10.10.30.46:5060 SIP/2.0 Via: SIP/2.0/UDP 10.10.30.212:5098;branch=z9hG4bK0a5b6af05e2ed0

From: sip:Environment@10.10.30.212:5066;tag=0F2DC9A6-2F17-486C-58AD-B84E3F788C86 To: sip:Environment@dev-photon:5060;tag=61B43FC6-F841-4326-A4F8-A8DA34DE627B-1 Max-Forwards: 70 CSeq: 1 NOTIFY Call-ID: 09142015-1524-4EF8-8FE6-F3AA8898F0BD-1@10.10.30.46 Contact: <sip:GVP@10.10.30.212:5098> Content-Length: 77 Content-Type: application/ x-genesys-mediaserver-status Supported: timer Environment/mcp1.com:5070/in-service Environment/mcp2.com:5070/out-of-service

Selecting a Resource

Service Capabilities

After the Resource Manager has mapped a new SIP request to a service, it allocates the request to a logical resource group that can provide the service with the specific capabilities required by the VoiceXML or CCXML application.

The Resource Manager uses two sources to identify what the capability requirements are:

The IVR Profile service policies, which are configured in the gvp.policy configuration section in the IVR Profile object.

Information that is parsed from SIP Request-URI parameters that have the gvp.rm.resource-req prefix. The Resource Manager does not forward these Request-URI parameters unless a CTIC resource is selected and the parameter rm.pass-capability-params-to-ctic is set to true.

Locating Resources Using Geo-Location

In multi-tenant environments, requests from gateway resources are parsed for the X-Genesys-geo-location custom header.

You can configure geo-location for an LRG through the Resource Group Wizard within Genesys Administrator. See "Configuring Logical Resource Groups" beginning on page 89 in the GVP 8.5 User's Guide.

If the custom header is included in the request, the RM checks the configured geo-location parameter for each resource group to determine if the geo-location parameter matches the location in the request.
If the RM finds more than one group that matches the geo-location information, it routes the call to the group that best meets criteria such as preference and capability.
If no groups match the geo-location, or the groups that match do not have available ports:
- The RM routes the call to any group that has available ports, even if the location information does not match. Unless...
- If the Service Type of the call request is configured in option reject-on-geo-location-nomatch, or if the request INVITE contains the X-Genesys-strict-location:enforce header, the Resource Manager will not route the call to any Logical Resource Group (LRG) whose geo-location does not match the geo-location specified in the INVITE. Instead, the Resource Manager will reject the call.
  You can use the option reject-on-geo-location-nomatch to configure Service Types that require strict geo-location matching.
  For example, reject-on-geo-location-nomatch = conference, recordingclient
  If the Service Type of the incoming INVITE is conference or recordingclient, RM will perform strict geo-location matching and reject the request in case no matching resources are found.
  With release 8.5.1, the option reject-on-geo-location-nomatch replaces the former option reject-recording-request-on-geo-location-nomatch, which specified this same behavior but only for calls being recorded. reject-on-geo-location-nomatch applies to all calls.
  In response to a call request from a gateway resource (SIP Server), the RM routes only to Logical Resource Groups (LRGs) with a geo-location that matches the geo-location specified in the INVITE message. If the RM cannot identify a matching LRG, it rejects the call.
  
  Tip
  These LRGs specify MCP (recording-client) or Recording Server (recording-server) resources. An LRG with no available MCPs and/or Recording Servers is considered non-matching, even if its geo-location is correct.

Load Balancing

After the Resource Manager has selected a logical resource group for the service request, it allocates the request to a physical resource. Except for conference services (see Resource Selection for Conference Services), the Resource Manager selects the physical resource based on the load balancing scheme for the group. The load balancing options are:

Round robin From a circular list, the Resource Manager selects the next resource whose usage has not exceeded configured limits.

Least used The Resource Manager selects the resource with the lowest usage that has not exceeded configured limits.

Least percentage used The Resource Manager selects the resource from the resource group with the least percentage of resource usage.

Usage is calculated in the manner specified by the port-usage-type parameter.

For more information, see the description of this parameter in the GVP 8.5 User's Guide.

Load Balancing in Resource Manager vs. in Media Control Platform

The Resource Manager load-balances within a logical resource group. It does not load-balance between resource groups.
The MRCP Client on the Media Control Platform, which provides Speech Resource Management (SRM), load-balances the selection of third-party speech engines with the same resource name (set to the option vrm.client.resource.name of each resource), on a round-robin basis.

Load-Balancing for Gateway Services

For gateway services, the Resource Manager selects a resource based on a configurable policy option that enables you to specify whether the call must be routed to the gateway resource that is already associated with the session, or whether the usual load-balancing scheme will be used (as specified in the IVR Profile gvp.policy.use-same-gateway configuration option).

If ESS is deployed, the Resource Manager uses a third source to identify the capability requirements (see Resource Selection for Conference Services), the X-Genesys-geo-location custom header.

Outbound-Call Distribution

The Resource Manager can use the prediction factor (factor-p) parameter to predict the ratio of agent calls to customer calls in a campaign, based on the assumption that factor-p can vary between 0.5 and 1.0.

A customer outbound call in a campaign is identified by the value of the X-Genesys-gsw-predictive-call SIP custom header. If the value is on, it is a customer call, if the value is off or the custom header is absent, it is identified as an agent call.

When the Resource Manager receives subsequent calls on an existing campaign, it finds the resource (Media Control Platform) with the maximum number of calls for that campaign that also has free ports, and uses the following process:

The Resource Manager examines the current number of agent calls (A), outbound calls (O), and free ports (F) on the Media Control Platform
If the new request is an agent call, and A - O < F x P, the Resource Manager places this call on the Media Control Platform.
If the new request is an outbound call, and O - A < F x P, the Resource Manager places this call on the Media Control Platform.
If the Resource Manager is unable to route the call to the Media Control Platform with the maximum number of call for that campaign, it finds the resource with the next highest number of calls for this campaign (with free ports) and it repeats Steps a, b, and c.
If the Resource Manager is unable to find a Media Control Platform by using these steps, it sends the request to a new Media Control Platform (if there is one available).

You can also set a factor-P value in the gvp.policy.prediction-factor parameter for IVR Profiles. If the value is not changed, 0.5 is the default value.

No Resource Selected

If the Resource Manager is cannot select a resource to meet the request, it responds to the SIP request with a configurable error message. For more information, see the section about customizing SIP responses in the GVP 8.5 User's Guide.

Resource Selection for Conference Services

Conference services have the special requirement in that the Resource Manager must route requests for the same conference ID to the same conference resource, even if the requests come from different Resource Manager sessions.

If the SIP Request-URI includes confmaxsize and confreserve parameters, and if the specified confmaxsize value is less than the confreserve value, the Resource Manager rejects the conference request.
For the first request that the Resource Manager receives for a conference (in other words, the Resource Manager is not already handling requests with the requested conference ID), it identifies eligible conference resources by matching the confmaxsize and confreserve requirements that are specified in the SIP Request-URI parameters with the conference maximums that have been configured for the IVR Profile and the resource group, taking into account the current status and usage of conference resources. For more information about the IVR Profile and resource group parameters that are considered, see the section about enabling conference services in the GVP 8.5 User's Guide.
The Resource Manager selects a resource for the conference by load balancing across the eligible resources, in accordance with the load-balancing scheme for the logical group (see Load Balancing).

The Resource Manager adds the confmaxsize and confreserve parameters to the outgoing Request-URI when it forwards the request.
When the conference session is successfully established, the Resource Manager increments the current usage of the resource by the expected size of the conference (as specified in the confreserve SIP Request-URI parameter; default is 1 if the parameter was not defined).
As new call legs join or leave the conference, the Resource Manager keeps track of the current conference size.
Tip
When the conference session is established, the maximum number of participants is the smallest among the conference size maximums(confimaxsize parameters) specified in the SIP request, the IVR Profile, and the resource group. As a result, the Resource Manager might internally modify the confmaxsize parameter in the outgoing SIP Request-URI, and this might cause the Resource Manager to reject the conference request if the confmaxsize parameter in the outgoing SIP Request-URI becomes smaller than the confreserve parameter (see Step 1 in this procedure).
When the Resource Manager receives subsequent requests with the same conference ID, it forwards each request to the same conference resource, provided that the maximum conference size is not exceeded.

If conference size maximums have not been defined in the SIP request, IVR Profile, or resource group, the Resource Manager forwards the request to the conference resource, leaving it to the conference resource to reject the request if necessary.

If the maximum size of the conference or the usage limit configured for the resource is exceeded when the new call leg is added, the Resource Manager rejects the request.

If a request is received for a new participant to join an existing conference, the Resource Manager detects that the conference resource has gone offline, and releases all the calls associated with the conference. When the new participants join the conference, the Resource Manager routes the requests to a new online conference resource with available ports.
If the Resource Manager cannot select a resource to meet the request, it responds to the SIP request with a configurable error message. For more information, see the section about customizing SIP responses in the GVP 8.5 User's Guide.

Resource Selection in HMT Environments

In HMT environments, the Resource Manager checks the Management Framework objects that it manages to determine if they are in an enabled or disabled state and processes requests, based on the following rules:

If a resource is disabled, new calls are not forwarded to that resource for processing.

If a resource group is disabled, it is excluded during resource selection for new calls.

If an IVR Profile is disabled, new calls for this profile are handled by the parent tenant s default profile. If a default profile is not defined, the call is rejected.

If a Tenant is disabled, new calls for this tenant are rejected.

The Resource Manager reads the state information for Management Framework objects during initialization. It also detects dynamic state changes during runtime.

Warning

Take great care when you disable tenant objects. Disabling a tenant does not disable its child tenants. But it does have a cascading effect on all of the objects that are owned by the tenant, including Resource Groups, resources, and IVR Profiles.

Exclusive Resources for Tenants

An enhancement to resource selection for HMT tenants, enables access to exclusive resources to specific tenants.

Previously, when resources were configured for a tenant, they were, by default, also available to its child tenants. Now when a tenant's DBID is configured in the parent tenant's tenant.N option, the child tenant cannot use the resources. In addition, the tenant.N option could be configured to allocate resources to a specific subset of child tenants.

Now, you can add the exclusive configuration option to the gvp.resources section in the GVP Configuration Unit (CU). When this option value is set to true, the resources under the CU are dedicated to the tenants that are specified in the tenant.N option only. Thus:

Set the parent tenant s DBID in tenant.N to exclude the children from using those resources.

Set the child tenant s DBIDs in tenant.N to exclude the parent from using those resources.

Therefore, if the parent tenant's DBID is configured in the tenant.N option, the child tenants cannot use the specified resources. Conversely, if the child tenant's DBID is configured in the tenant.N option, the parent tenant cannot use the specified resources.

If the exclusive configuration option value is set to false, or if it is not configured in the CU, resource allocation occurs as described Resource Selection in HMT Environments.

Failed Requests

The behavior of the Resource Manager in response to failed requests depends on the type of service, and on the failure response code received by the Resource Manager:

For voicexml, ccxml, conference service and CTI Connector requests for which it receives a 4xx or 5xx response code, the Resource Manager tries to select another resource, in accordance with the load-balancing scheme for the group, until it has tried all resources in the group.
For a gateway services request for which it receives a 4xx or 5xx response code, or for which the request times out, the Resource Manager forwards the failure response to the User Agent Client (UAC).
For any INVITE requests to create a new SIP dialog for which it receives a 6xx response, the Resource Manager immediately forwards the response to the UAC, without trying to select another resource.

If the Resource Manager receives no successful 2xx responses, but it does receive at least one final response from one of the resources, it forwards one of the received responses to the UAC, in the order of selection shown in this table:

**Table: Order of Selection for Responses to the UAC**
	Response Received	Response Returned to the UAC
1.	6xx	6xx
2.	401, 407, 415, 420, 484	401
3.	Any other 4xx response	The first 4xx response received
4.	Any 5xx other than 503	The first 5xx response received
5.	500 Server Internal Error	500 Server Internal Error

If the Resource Manager has sent at least one request to a resource, but it has not received any final responses from any resource, it sends a 408 Request Timeout response to the UAC.

For more information about the SIP response codes that GVP components generate, see the appendix about SIP response codes in the GVP 8.5 User's Guide.

Failed ASR/TTS Reservation Requests

If the Media Control Platform rejects a SIP INVITE request and the service-type is voicexml, the Resource Manager processes a Warning header, if configured, to check the specified warning code. A 390 warning code indicates an ASR reserve failure and a 391 warning code indicates a TTS reserve failure.

When Resource Manager receives these types of warning codes, it checks the gvp.policy.speech-reserve-failure-retry parameter in the profile:

If it is not configured in the profile or is set to true, the Resource Manager routes the call to another Media Control Platform in the same resource group.

If it is set to false, the Resource Manager checks the value of the gvp.policy.speech-reserve-failure-response configuration option to see if it is set to a valid SIP error response code (by default, set to 0). If it is, this response code is returned to the UA. If it is not, the response sent from the Media Control Platform is returned.

Recording Server and Client Resources

Resource Manager manages recording servers and recording clients by detecting and monitoring them to provide and facilitate GVP Call Recording services. In the Call Recording solution, the Resource Manager functions include:

Provisions third-party recording servers.
Provisions Media Server resources.
Handles load balancing and failover of Media Servers.

For more information about how the Resource Manager manages Reporting Servers and Clients, see the section Recording Servers and Clients in Chapter 2 of the Genesys Media Server 8.5 Deployment Guide.

Multi-Site Resources

The Resource Manager supports GVP multi-site configurations, which consist of multiple single-site deployments, with each site consisting of a Resource Manager instance (or an HA pair), a Reporting Server instance (or an HA pair), and multiple Media Control Platform instances. The Resource Manager shares resources and enforces policies consistently across all sites. In addition, administrators can generate real-time and historical reports with or without site identification filters, which means they can also generate system-wide reporting data.

Site Identification

Resource Manager obtains information about GVP sites by checking the site folder object, which is configured in Management Framework and can be viewed in Genesys Administrator on the Provisioning tab, under Environment > Applications. The folder Annex contains a gvp.site configuration section, in which site configuration options are kept. They include the following parameters:

Weight Relative weight for this site.
Geo-Location Comma-separated list of geo-locations associated with this site.
Resource Sharing Whether resource sharing is enabled or disabled for this site.
Contact The SIP route address for this site.

The Resource Manager uses the name of the site folder in Management Framework for the site name. It must be unique within the Applications folder. The site ID is taken from the site folder s DBID and must also be unique. The site folder contains only Resource Manager and Reporting Server components.

Parsing Site Configuration

The Resource Manager in each site reads the local site configuration as well as the configurations of the remote site in the deployment and subscribes to notifications for the site object configuration changes. If the weight factor, or any other site properties change, the Resources adjusts its site information accordingly.

Monitoring Other Sites

The Resource Manager in each local site monitors the remote sites, by using SIP OPTIONS messages to ping the Resource Managers in those sites. To do this, it uses the contact parameter that is provided in the gvp.site configuration section of the remote sites folder. In this way, each Resource Manager can determine when the remote sites are online or offline.

Multi-Site Policy Enforcement

The Resource Manager enforces policies dynamically across the multiple-site deployments, by using usage-based counters only (Type I policy enforcement). All other policy enforcement types (Type II, III, and IV) are enforced locally on a per-site basis. (See Policy Enforcement Types.)

For detailed information about the usage-based counters, see Usage Limit Counters.

Multi-Site Resource Sharing

The Resource Manager can manage resource sharing across multiple sites. Any site can be selected to enable resource sharing by setting the gvp.site.resource-sharing configuration option value to true (default) in the site folder. When resource sharing is enabled, and there are no Media Control Platform resources available, the local-site Resource Manager can insert a routeset parameter to forward requests to this site. The Resource Manager only forwards requests to sites that have resource sharing enabled. In this case, policy enforcement is done at the local site.

The Resource Manager adds a X-Genesys-GVP-Site-ID custom header to the request its own site ID set as the value. This enables other sites to determine the originating site for the request and whether or not further policy checking is required.

Resource sharing applies to the Media Control Platforms only. If a CTI-Connector or Call Control Platform resource is required for a call and there are no ports available, the Resource Manager does not forward the request to a remote site and the existing logic for handling these kinds of requests is used. See How the Resource Manager Works.

Multi-Site Reporting

In GVP multi-site environments, Reporting Server collects data from all GVP segments to generate historical and real-time reports on a per-site or system-wide basis. The Resource Manager logs the site ID into the CDR to identify the site, to which the data applies.

For a detailed description of how multi-site reporting works, see GVP Multi-Site Reporting.