Jump to: navigation, search

How the MRCP v2 Proxy works

This section provides information about the following topics, to explain how the MRCP v2 Proxy (MRCPv2Pxy) Server performs its role in a GVP deployment:

Operational overview

MRCPv2Pxy accepts client session SIP requests (from Media Control Platform) and sends these requests to ASR and TTS speech servers by using SIP protocol to establish the initial SIP session with the resources. Once the session is established, MCP creates the control session to the corresponding MRCP resource via TCP / TLS and sends requests by using MRCPv2.

Resource management

MRCPv2Pxy obtains a list of MRCPv2 resources from Management Framework and maintains an up-to-date picture of the resource pools or resource groups.

Similar to Resource Manager, these resource groups are nothing but Logical Resource Groups whose service-types can be 'asr' or 'tts'.

MRCPv2Pxy pools all these resources and keeps pinging them via SIP OPTIONS (if enabled in the LRG configuration).

If the ping fails, the resource is declared offline and will be removed from the pool of resources to which MRCP SIP session requests will be forwarded.

Only the speech resources with the engine name (for example, provision.vrm.client.resource.name) that are requested by the Media Control Platform are considered for matching.

Important
Multiple speech servers can be configured in one MRCP v2 Proxy.

Resource and application updates

MRCPv2Pxy receives and processes updates from Management Framework for its configured resources and application objects in the following way:

  1. Any addition of MRCP resources to the LRGs configured for the MRCPv2Pxy will be processed and new resources will be immediately taken into consideration for further resource session establishments.
  2. Any deletion of MRCP resources from LRGs configured for MRCPv2Pxy will be processed and the resources will be removed. However, the existing SIP sessions will be taken to completion.
  3. Any modification to MRCP resource configuration monitored by MRCPv2Pxy will be processed and the changes will take effect immediately.

High availability

MRCPv2Pxy provides the following modes of availability:

Active-standby (warm standby only)

MRCPv2Pxy provides warm-standby mode of HA depending on the configuration via SCS similar to MRCPv1Proxy. LRG pools for ASR/TTS resources should have the DBIDs of both MRCPv2Proxies configured for HA.

Two servers are required for this configuration: one configured as the primary server and the other as the backup server.

Management Framework's Solution Control Server determines which server is active and which is on standby at any given time.

The standby MRCP Proxy puts itself into suspended mode and does not submit data to the Reporting Server nor does it respond to incoming SIP requests; only the active server performs these functions.

When failover occurs, the existing connections are terminated and all of the existing ASR/TTS sessions are lost. In addition, when the standby machine becomes active, the peak ASR and TTS usage counter is reset to zero.

Standalone

In this mode, only one instance of MRCPv2Pxy will be running. There is no HA.

Data collection and logging

MRCPv2Pxy uses the Operational Reporting (OR) interface to send ASR and TTS usage data to the Reporting Server in real time. It submits the following usage information:

  • ASR and TTS peak data for a specific speech resource
  • ASR and TTS arrival data for a specific speech resource
  • ASR and TTS peak data for a specific tenant
  • ASR and TTS arrival data for a specific tenant
  • ASR and TTS peak data for a specific IVR Profile
  • ASR and TTS arrival data for a specific IVR Profile
  • ASR and TTS peak data for the entire deployment

MRCPv2Pxy reports ASR and TTS usage data for tenants, IVR Profiles, or the entire deployment. The MRCPv2Pxy receives the tenant and profile information from the Media Control Platforms for each speech resource request. This information is sent to the Media Control Platform originally from the Resource Manager, based on the tenant/profile mapping.

Configuring MRCP v2 Proxy

Set mrcpv2pxy.enable_mrcpv2_proxy=1 for the installed MRCPv2Proxy application (RM application type) and it starts working as MRCPv2Proxy application.

Creating resource groups (ASR / TTS) to be used by MRCPv2Pxy

Genesys Administrator cannot be used for creating LRGs to be used by MRCPv2Proxy. Only CME way of creating LRGs is supported since the service-types 'asr' and 'tts' are not supported by GA.

Procedure for creating an LRG of service-type 'tts'

  1. Create a folder of 'Configuration Unit' type under Environment tenant.
  2. Under 'Annex' tab of the CU folder, create a section named 'gvp.resources'.
  3. Under the section 'gvp.resources', specify the following parameters:
    • rm_dbid - Set this to the DBID values of the MRCPv2Proxy application pair. The values should be separated by comma.
    • tenant.1 - Set this to '1'.
  4. Click Ok and create the CU folder.
  5. Under the CU folder, create a folder of 'Application' type. This application folder will be the LRG configured for specific service-type as shown below.
  6. In the 'Annex' tab of the Application folder, create a section gvp.lrg.
  7. Under the gvp.lrg section, create the following parameters:
    • load-balance-scheme - Set this to the default 'round-robin'. For other values for this parameter, refer to Resource Group configuration for Resource Manager.
    • monitor-method - Set this to 'option'.
    • port-usage-type - Set this to 'outbound'.
    • service-types - Set this to 'tts' (for an ASR LRG, set this value to 'asr').
  8. Click Ok, and the LRG of service-type 'tts' is created.
  9. Under this LRG folder, create/move MRCPv2 resources which will be considered as MRCPv2 resource pool by the MRCPv2Proxy (pair).

Procedure for creating an LRG of service-type 'asr'

The procedure is same as the procedure above (that is, for creating an LRG of service-type 'tts'), except that when specifying 'service-types', it should be set to 'asr' instead of 'tts'.

MCP configuration

This section covers the configuration required of MCP application to work with MRCPv2Pxy. This is slightly different from how MRCPv1Proxy is configured with MCP.

New parameter in MCP configuration

A new parameter client.mrcpv2.proxy is added to MCP configuration under the vrm section.

This parameter indicates whether MCP has representatives (ASR/TTS Resource Access Point - RAP - application objects) of MRCPv2Pxy application in its configuration.

When set to true, MCP will identify RAP resource added to the Connections tab as MRCPv2Pxy instead of MRCP v2 Server resources.

When set to false, MCP will consider the ASR/TTS RAP application objects as MRCP Servers instead of being representatives of the MRCPv2Pxy application.

The default value is set to false.

How to configure ASR / TTS resource object to represent MRCP v2 Proxy application

A separate pair of ASR/TTS RAP objects must be created for each of the primary and backup MRCPv2Pxy to represent a separate service provided by the MRCP server. For example, for a representative TTS resource to represent a MRCPv2Pxy, a separate TTS RAP object must be created, configured, and added to the Connections tab of MCP. Likewise, for a representative ASR resource to represent the MRCPv2Pxy, a separate ASR RAP object needs to be configured and added to the Connections tab of MCP.

For each of the ASR/TTS RAP resource, under the Options tab, under the provision section, vrm.client.resource.uri is set to the MRCPv2Pxy IP address and port number in the form of SIP AOR. For example, sip:mresources@<MRCPv2Pxy_IP>:<MRCPv2Pxy_Port>. This MRCPv2Pxy_Port is the port available under the proxy section of the MRCPv2Pxy application object.

Since each pair of ASR/TTS RAP represent an MRCPv2Pxy object, two pairs of ASR/TTS RAP objects must be created to represent the primary and backup MRCPv2Pxy application objects and added to the Connections tab of MCP.

Steps to configure ASR/TTS RAP pair objects

  1. Set vrm.client.mrcpv2.proxy to true for the MCP object that needs to use the MRCPv2Pxy application.
  2. Create a new Resource Access Point (RAP) object for MRCP TTS service.
  3. Configure the provision section. Specify the vrm.client.resource.type as 'TTS'.
  4. Set vrm.client.resource.uri parameter to the MRCPv2Pxy IP address and port number in the form of SIP AOR. For example, sip:mresources@<MRCPv2Pxy_IP>:<MRCPv2Pxy_Port>.
  5. Add the new RAP object to the Connections tab of MCP.
  6. Create another RAP object for MRCP ASR service.
  7. Configure the provision section vrm.client.resource.type as 'ASR'.
  8. Set vrm.client.resource.uri parameter to the MRCPv2Pxy IP address and port number in the form of SIP AOR. For example, sip:mresources@<MRCPv2Pxy_IP>:<MRCPv2Pxy_Port>.
  9. Add the new RAP object to the Connections tab of MCP.

How MCP pings the MRCP v2 Proxy application

MCP continuously sends SIP OPTIONS ping to resources that are representing MRCPv2Pxy object to check their status and routes the incoming ASR/TTS calls based on status of the MRCPv2Pxy and resource requested. This means that for a pair of ASR/TTS RAP objects that represent an MRCPv2Pxy, there will be two independent SIP OPTIONS sent.

In the MRCPv2Pxy HA configuration, MCP continuously sends OPTIONS ping to both primary and backup MRCPv2 proxies.

To these pings, only the primary MRCPv2Pxy server responds so all the MRCP service requests are routed through primary proxy. When the primary goes down, SCS identifies it and brings up the backup MRCPv2Pxy application. Now, MCP receives OPTIONS response only from backup proxy so all the MRCP service requests are routed towards the backup proxy.

Retrieved from "https://docs.genesys.com/Documentation:GVP:GDG:HGWMv2P:9.0.x (2019-05-25 01:50:07)"
This page was last modified on January 17, 2019, at 23:59.

Feedback

Comment on this article:

blog comments powered by Disqus