The following appendixes contain information useful in specific scenarios.

A: Folder and Registry Access Permissions

Understanding Web Services and ASP.NET

Web Services are set up under IIS as both Applications and Web Sites. When the Web Sites are accessed, they can be set up to allow anonymous user access, or they can require a valid domain user/password. When anonymous access is allowed, the Web Sites will reference the Web Services by using the IUSR_<SERVERNAME> user intended for this purpose, or by impersonating a valid user (this impersonated user can be changed within the Web Site settings in IIS). The IIS VHDefaultAppPool houses most of the Web Services, and needs to be able to access local files on the server where the Web Services reside. The VHDefaultAppPool will access the local files via the user account that is associated with it. This is configurable within IIS as well. This user account must have certain permissions to be able to access the local files on the server.

General Overview of Permissions

• The Virtual Hold Log File Path.
• The Virtual Hold Registry Settings (HKEY_LOCAL_MACHINE\SOFTWARE\Virtual Hold and HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Virtual Hold).
• The Virtual Hold IIS Path.
• The Virtual Hold Databases (VHT_Config, VHT_RPT). The Virtual Hold Databases will be created by the Virtual Hold installer, and those permissions will be established at that time.
• The IIS Virtual Hold application pool, and the Virtual Hold Web Applications and Web Services.
• Certain local folders.

B: Editing Web.config Files

Overview

<caching>    <cache disableMemoryCollection = "true"    disableExpiration = "false"    privateBytesLimit = "0"    percentagePhysicalMemoryUsedLimit = "90"    privateBytesPollTime = "00:02:00"/></caching>

C: Editing OutboundIVR_AVP.xml Files

In an Avaya environment, the OutboundIVR application requires a template file (OutboundIVR_AVP.xml) which contains the settings it needs to send the correctly formatted outbound call request to AVP/AEP.

You will need to configure the the OutboundIVR_AVP.xml file if you will be using any of the features below.

Sample OutboundIVR_AVP.xml

Changing WebService Client Timeout

<WebServiceClientTimeoutInMilliSeconds>180000</WebServiceClientTimeoutInMilliSeconds>

Enabling the Answering Machine Detection Feature

In On-Premise Callback integrations using Outbound IVR with AVP, this feature allows Callback to detect when an answering machine has answered a call. To enable this feature, ensure the following session parameter is set as indicated:

<SessionParameter>enable_call_classification=true;detect_greeting_end=true</SessionParameter>

Enabling the Agent Priority Feature and Increasing Timeout

In Avaya TSAPI environments (AVP or AEP) using the Agent Priority feature, the OutboundIVR_AVP.xml file must be configured to look for a CCXML application name, in addition to the standard outbound application name. This CCXML application is used when a queue is in Agent Priority mode, to connect to an agent first before launching a callback to the customer.

The ConnectTimeout value must also be increased to allow extra time for Agent Priority processing.

On all On-Premise Callback servers containing an instance of Outbound IVR, configure the CcxmlApplicationName attribute with the Agent Priority CCXML application name configured in Avaya.

For AEP 7.0.1, set the ConnectTimeout value to 120.

For AEP 7.2.2, set the ConnectTimeout value to 59.9999999999999999999 (due to the decreased max timeout in this version).

<CcxmlApplicationName>[CCXML Application Name]</CcxmlApplicationName>...<ConnectTimeout>120</ConnectTimeout>

Configuring Multiple Connection Sets

Multiple connection sets can be configured in environments where queue-level differences in the connection need to be configured. For example:

• You may require a different ANI to be presented for each queue.
• Outbound dial requests for different queues may need to exit your environment through a different location.
• Call Progress Detection parameters may be different for some queues.

Follow these steps to add multiple connection sets to the OutboundIVR_AVP.xml file:

• Identify how many Connection Sets are needed, and modify the NumberOfConnectionSets attribute with the appropriate value.

<NumberOfConnectionSets>3</NumberOfConnectionSets>

• Copy everything within ConnectionSet1 attribute and paste directly below closing tag.
• In the pasted section, change ConnectionSet1 to ConnectionSet2 in both the opening and closing tags.
• Change the value of the Identifier attribute to the Callback Queue ID for the queue you are configuring:

<Identifier>My_Queue_ID</Identifier>

• Modify the value of the OutboundANI attribute with the appropriate value:

<OutboundANI>3305557777</OutboundANI>

• Repeat these steps, increasing each connection set count by one, until all connection sets are configured.

Enabling Call Throttling/Load Balancing

• Change the value of the Count attribute in the Connection set to reflect the number of connections (2).
• Change the value of the LastConnection attribute to the final connection in the set (in this case Connection2).
• In Connection1, change the values of the NextConnectionOnFailure and NextConnectionOnNoResourcesAvailable attributes to Connection2.
• Copy everything within the Connection1 attribute and paste directly below the closing tag.
• In the pasted section, change ConnectionSet1 to ConnectionSet2 in both the opening and closing tags.
• Change the value of the NextConnectionOnSuccess attribute to Connection2.

OutboundIVR will use Connection1 first and continue using that connection until there is an issue. It will then attempt to use Connection2. It will continue using Connection2 until there is a problem and then switch back to Connection1. If the call is not successfully answered, the outbound call is handled like a normal failed callback.

If you have upgraded from an earlier version of On-Premise Callback, make sure the NextConnectionOnNoResourcesAvailable parameter is present in the <URLParameters> section in each connection, within each Connection Set. The parameter must contain the name of a connection listed in the associated Connection Set.

K: Editing OutboundIVR_SSG.xml Files

Enabling Answering Machine Detection

In Virtual Hold integrations (ORS or URS) using the Outbound IVR with Genesys, this feature allows Virtual Hold to detect when an answering machine is responding to Virtual Hold-initiated calls. To enable this feature:

• On all Genesys SIP Servers, set the am-detected (answering machine detection) option to connect.
• On all Virtual Hold servers containing Outbound IVRs, ensure the following code is set as indicated in the OutboundIVR_SSG.xml file:

<cpd>    .    .    .    .    <detect>voice,am</detect></cpd>

For further information on the <cpd> attributes, please reference the Genesys Media Server Deployment Guide.

Configuring secure connections to SSG

Secure connections can enhance data protection and help to satisfy regulatory requirements. Use the following steps to secure your connection:

• Import the same CA certificate used for your SSG instance to the Windows Trusted Root CA certificate store on your Callback Peripheral server(s).
• In the OutboundIVR_SSG.xml file (located in the Virtual Hold Technology directory), update the URI element of each connection to use HTTPS (see below).
• Restart the VHT Peripheral Monitor service to apply the changes.

Example

        ...        <Connection1>            <URI>https://REPLACESERVERNAME:9800/SSG&lt;/URI>            ...        </Connection1>        ...

D: Uninstalling Callback

To uninstall all of the Callback software, use standard Windows practices to remove the Callback Software entry from Add/Remove Programs. This uninstalls the Callback Software program and all other Virtual Hold applications at once on the server. Do this process on all servers that have Virtual Hold software installed.

• All Callback services and registry settings are removed. All logs directories and logs are not removed. Existing databases are not removed.
• Uninstalling Callback software does not remove existing Datastore files. These files are used by the reinstalled Callback software to restore all ASAP and scheduled calls. To completely remove these calls, delete all files in the VH_root_directory\Datastore Files directory. The VH_root_directory is C:\Program Files (x86)\Virtual Hold Technology by default.

E: Installing the TSAPI Client

Overview

During Virtual Hold installation, when the TIAL Avaya TSAPI switch type is selected in the Core Role Configuration window, a directory named "TSAPI Client" is created in the Virtual Hold install path. You must manually run the setup program in this directory to configure the TSAPI client.

Installing the TSAPI Client Files

• On the first Core instance server, navigate to the Virtual Hold Technology folder. The default location is C:\Program Files\Virtual Hold Technology\TSAPI Client.
• Double-click the setup.exe file. The Welcome window is displayed.
• Click Next. The Choose Destination Folder window is displayed.
• Choose the appropriate destination on the Core instance server. The default location is C:\Program Files\Avaya\AE Services\TSAPI Client\.
• Click Next. The TCP/IP Name Server Configuration window is displayed.
• Enter the following information:
  • Host Name or IP Address: Enter the information for the AES server.
  • TCP Port: Enter the port number that will be used on the AES server. The default is 450. Click Add to List, to move your selections to the Configured Telephony Servers field.
 Note: For Multiple TSAPI integrations, simply add the IP Address and Port number for additional AES servers.
• Click Next. The Installation Complete window is displayed.
• Click Finish.
• Repeat these steps on the second core server if applicable.

Testing the TSAPI Client Installation

• Navigate to the TSAPI Client installation folder. The default location is C:\Program Files\Avaya\AE Services\TSAPI Client\Program.
• Double-click TSTEST32.exe. The TSAPI Test Application window is displayed.
• During configuration, the information in the Server field in this window should be entered into the Server ID field in the AES Avaya CTI window in the Virtual Hold Configuration Wizard. Copy the information in this field and save it for later.
• To test the TSAPI Link, enter the User ID and Password of the AES server, and then enter a valid extension number in the From: field and another valid extension number in the To: field, and then click Dial. A dialog box will open:
• The To: station should ring. Click OK to close the dialog box and stop the ringing.
• Close the TSAPI Test Application window.

F: Configuring HMP Systems

Use the HMPMessagingIPAddress registry setting for all HMP systems. Also, ensure that the IP Address for your RTP traffic is configured in Dialogic DCM:

• Open DCM.
• Select the proper device, HMP_Software....
• Right-click and select Configure Device.
• Select Default IP Address—ensure the correct IP Address is selected.

G: Modifying Result Codes in VHT_Message_Bus

<CallInfos>
         
	<--!Valid Types are CALLINFO_CALLBACK_FAILED, CALLINFO_CALLBACK_SUCCESSFUL, and CALLINFO_CALLBACK_CANCELLED-->
	
	<CallInfo clientCode="SUCCESS" type="CALLINFO_CALLBACK_SUCCESSFUL"  value="CALLINFO_NODATA" />
	<CallInfo clientCode="CANCELLED" type="CALLINFO_CALLBACK_CANCELLED" value="Callback Cancelled" />
	CallInfo clientCode="NO ANSWER" type=""CALLINFO_CALLBACK_FAILED" value="No Answer" />
	CallInfo clientCode="Busy" type="CALLINFO_CALLBACK_FAILED" value="Busy" /
	CallInfo clientCode="No Response" type="CALLINFO_CALLBACK_FAILED" value="No Response" />
	CallInfo clientCode="AnsweringMachine" type="CALLINFO_CALLBACK_FAILED" value="AnsweringMachine" />
	
</CallInfos>

H: Using ANI to Track Calls

• Ensure the switch uses phone number as the ANI value.
• Set the ExternalTrackingId registry setting value to ANI.
• Ensure the Outbound Contact Client is installed and configured.

I: Changing Instance Host Names

This file must be identical in all Peripheral and Core instances in the cluster.

• Open the file .hosts.erlang, located in the following locations, with a text editor:
  • For the Core Instance, at C:\Program Files (x86)\Virtual Hold Technology\Core Monitor\monitor.
  • For the Peripheral Instance, at C:\Program Files (x86)\Virtual Hold Technology\Peripheral Monitor\remote_client.
• Change the fully qualified host names as required and save the file.
• Replace the .hosts.erlang file in all remaining Peripheral and Core instances in the cluster with this modified file.

J: Changing Dashboards Log Levels

• Open the appropriate configuration file using a text editor.

• Set the loglevel parameter to the desired number.
• Save the configuration file.
• Restart the service.

L: Genesys ICON Reporting Support

Virtual Hold integrations with Genesys Version 8 can use the ICON application for the reporting of event statistics. Proper configuration of a Virtual Hold registry setting allows the Genesys universally unique identifier (UUID) attached to incoming Genesys events to be reattached to the outgoing event route request commands. Having this UUID attached allows ICON to track Genesys events and report on their status.

To enable this functionality, set the HKEY_LOCAL_MACHINE\SOFTWARE\Virtual Hold\Genesys\UseUuid registry setting to TRUE on all Core servers in the Virtual Hold integration.