Release Note

Universal Callback Server

7.1.x

Genesys Telecommunications Laboratories, Inc. © 2005–2008

Contents

Introduction

This release note applies to all 7.1 releases of Universal Callback Server.

  • Links in the Contents section enable you to access information regarding a specific release. Releases are listed by version number rather than in date order. For this reason, a recent release may be listed after earlier releases, if the version number is lower. Except when otherwise noted in the information for a specific release, each release includes all of the features and corrections that were introduced for the applicable operating system at earlier dates, regardless of the version numbering.
  • The Release Number table lists the supported operating systems for each release at a high level. For more detailed information, see the Genesys Supported Operating Systems and Databases Reference Manual.
  • The Known Issues and Recommendations section is a cumulative list. It includes information on when individual items were found and, if applicable, corrected.
  • The Corrections and Modifications section for each release may list additional issues that were corrected without first being documented as Known Issues.
  • The Discontinued Support section is cumulative. It lists functionality that is no longer supported and the release number of the version in which support was discontinued.

Note: Genesys follows applicable third-party redistribution policies to the extent that Genesys solutions utilize functionality of commercial or non-commercial third parties.

Release Number 7.1.000.24 [08/22/2008] - Hot Fix

New In This Release
Corrections and Modifications

New In This Release

This is a hot fix release for this product. This release does not contain any new features or functionality.

Corrections and Modifications

This release includes the following correction or modification:


When working with Universal Contact Server, Universal Callback Server now always forms a correct request to create interactions for ASAP type callbacks. Previously, on some UNIX platforms, Universal Callback Server was unable to create interactions for ASAP type callbacks with Universal Contact Server. This prevented callback records from being stored in the Universal Contact Server database. (ER# 54634295)

Top of Page

Release Number 7.1.000.23 [06/15/2007] - Hot Fix

New In This Release
Corrections and Modifications

New In This Release

This is a hot fix release for this product. This release does not contain any new features or functionality.

Corrections and Modifications

This release includes the following corrections and modifications:


The loss of callbacks is now minimized in a switchover scenario for Universal Callback Servers (UCS) as follows:

  1. The new backup server clears the virtual callback queue by sending an EventAbandoned message.
  2. The new backup server then deletes the virtual calls that were submitted to the queue, but had not been delivered to any agents.
  3. The new primary server retrieves records from the database and resubmits the callbacks that had not been delivered to the agents.

(ER# 73702946)

Top of Page

Release Number 7.1.000.22 [09/11/2006] - Hot Fix

New In This Release
Corrections and Modifications

New In This Release

This is a hot fix release for this product. This release does not contain any new features or functionality.

Corrections and Modifications

This release includes the following corrections and modifications:


This version of Universal Callback Server now checks configuration settings during startup in scenarios where it fails while trying to open an LCA connection. When the Universal Callback (UCB) application is configured as standalone (redundancy type = Not Specified), UCB will start as primary. In all other cases, the initial mode for UCB is backup. (ER# 12612317)


Virtual Route Point (VRP) and Route Point (RP) DNs are now properly registered in scenarios where the primary server switches to backup mode and then switches back to primary mode again. (ER# 49713085)


In this release of Universal Callback Server, callback requests are not accepted and records are not read from the database (backup mode to primary mode switchover requests), when the Virtual Route Point (VRP) is unregistered after Universal Callback (UCB) is manually terminated, until the VRP is properly registered again. UCB now checks the status of registration requests once or twice per second. If a response returns an error, a new request is issued. Previously, Universal Callback Server did not attempt to register a VRP again if the first attempt failed, and a UCB failover would not have been successful. (ER# 19525811)

Top of Page

Release Number 7.1.000.18 [03/14/2006] - Hot Fix

New In This Release
Corrections and Modifications

New In This Release

This is a hot fix release for this product. This release does not contain any new features or functionality.

Corrections and Modifications

This release includes the following corrections and modifications:


This version of Universal Callback Server is available on the Solaris platform. It includes all fixes made in all prior versions.


Universal Callback Server now exits with the log message Error reading Environment tenant when incorrect data for the Environment Tenant is retrieved from Configuration Server. Previously in this scenario, Universal Callback Server abnormally terminated on startup.

Note: This applies only with version 6.5 of Configuration Server. The corresponding issue has been fixed in patch version 6.5.000.25 of Configuration Server.

(ER# 33751261)

Top of Page

Release Number 7.1.000.17 [01/20/2006] - Hot Fix

New In This Release
Corrections and Modifications

New In This Release

This is a hot fix release for this product. This release does not contain new features or functionality.

Corrections and Modifications

This release includes the following corrections and modifications:


This version of Universal Callback Server extends the functionality of the RequestCallbackQuery and RequestCallbackQueryResult requests for Universal Callback Server Client-Server communication protocol. These requests have a new attribute called VCB_QUERY_SCOPE that permits more flexibility when querying callback information when a Route Point DN is used to send a query. This query scope can be extended to a switch or tenant level by using a VcbQuerySwitch or VcbQueryTenant value respectively for the VCB_QUERY_SCOPE attribute. Previously, if a query request came to a Route Point DN, the query scope was limited to that Route Point DN only. This version is built for the Windows platform. (ER# 29686042)


Universal Callback Server 7.1 requires Universal Routing Server 7.2 and Stat Server 7.2 to correctly process callback requests in environments with Aspect and Alcatel 4400 T-Servers. (ER# 71833, ER# 87469)

Top of Page

Release Number 7.1.000.16 [12/13/2005] - Hot Fix

New In This Release
Corrections and Modifications

New In This Release

This is a hot fix release for this product. This release does not contain new features or functionality.

Corrections and Modifications

This release includes the following corrections and modifications:


Universal Callback Server no longer enters into a continuous loop when two or more callback requests with the same phone number are created on different routing points and RequestCallbackQueryResult is issued for this phone number. This version is built for the Windows platform. (ER# 27452761)

Top of Page

Release Number 7.1.000.15 [11/09/2005] - Hot Fix

New In This Release
Corrections and Modifications

New In This Release

This is a hot fix release for this product. This release does not contain new features or functionality.

Corrections and Modifications

This release includes the following corrections and modifications:


Universal Callback Server now correctly resets the value of the VCB_CALL_RESULT attribute to unknown for the callback's UserData attribute before any dialing attempt. Previously, a treatment could have been incorrectly applied on an answered call based on the value of the VCB_CALL_RESULT attribute from a previous dial attempt. (ER# 20434241)


Universal Callback Server no longer abnormally terminates when the values of the VCB_TYPE attribute in a callback submission is incorrect. (ER# 22440058)

Top of Page

Release Number 7.1.000.13 [10/14/2005] - Hot Fix

New In This Release
Corrections and Modifications

New In This Release

This is a hot fix release for this product. This release contains the following new features and functionality.


Universal Callback Server (UCS) is now able to perform outbound predictive dialing from one switch and route the callbacks to agents at a different switch when a Call Progress Transfer DN is configured.

UCS will perform a Predictive Call on the DN and switch specified in the following two new Routing Point level options when a RequestRouteCall is received, and auto dialing is configured.

orig_dn
Default Value: No default value.
Valid Values: Any valid Routing Point in Configuration Manager.
Changes Take Effect: For callbacks dialed after the change was made.

Name of the DN to use as the call originator. When configured, this option has priority over the existing configuration model.

orig_location
Default Value: No default value (If not specified, the Routing Point switch is used).
Valid Values: Valid switch name.
Changes Take Effect: For callbacks dialed after the change was made.

Name of the switch where the call originator is located. When configured, this option has priority over the existing configuration model.

Note: These two new options have been introduced for enhanced configuration of the origination DN. They take priority over the existing call_progress_orig_dn option. (ER# 16167476)

Corrections and Modifications

This release does not contain any corrections or modifications.

Top of Page

Release Number 7.1.000.12 [10/04/2005] - Hot Fix

New In This Release
Corrections and Modifications

New In This Release

This is a hot fix release for this product. This release does not contain new features or functionality.

Corrections and Modifications

This release includes the following correction and modification:


Universal Callback Server now returns the correct result for the RequestCallbackQuery message when T-Server is configured for Load Balancing. (ER# 15451737)

Top of Page

Release Number 7.1.000.11 [08/12/2005] - Hot Fix

New In This Release
Corrections and Modifications

New In This Release

This is a hot fix release for this product. This release does not contain new features or functionality.

Corrections and Modifications

This release includes the following corrections and modifications:


This version of Universal Callback Server extends the functionality of the RequestCallbackQuery request from the Universal Callback Server Client-Server communication protocol. Previously this request required both attributes VCB_LOCATION and VCB_ROUTING_POINT to be specified. In the current version, both attributes are optional. Thus, the RequestCallbackQuery search criteria has been extended from the Routing Point-level (when both attributes are specified) to the Switch-level (only attribute VCB_LOCATION is specified) and further to the Application-level (both attributes are omitted). (ER# 6171375)


This version of Universal Callback Server resolves a defect that caused failures to deliver callback requests (both scheduled and ASAP) to agents in scenarios where Universal Callback Server disconnects and reconnects to a T-Server while these callbacks are being processed. The problem affected only those callback requests which were requested and processed via a T-Server with which Universal Callback Server had lost its connection. (ER# 9421851)

Top of Page

Release Number 7.1.000.10 [04/28/2005] - General

 New In This Release
Corrections and Modifications

New In This Release

There are no restrictions for this release. This section describes new features that were introduced in the initial 7.1 release of Universal Callback Server.

  • Universal Callback Server is now able to process callback requests originating from the Web, using a Web interface that enables callback ordering and management via the Web API Server.

  • The communication history between agents and customers, regardless of callback request origination (Web, IVR, Agent Desktop), is maintained by the Universal Contact Server in one centralized database that all agents may view. Universal Callback Server works as a client of Universal Contact Server, providing it with callback-related details. Universal Contact Server is an optional component.

  • Callback requests can originate from the Web, and Genesys Agent Desktop provides the same preview and autodial functionality for Web callbacks as it does for other sources of callback origin (IVR and Agent Desktop).

  • Time interval limitations for callback processing are set up when ordering the callback. The expiration time for the callback can be specified for any ordering interface (Web, IVR, Agent Desktop) and is supplied in the form of start time and end time attributes.

  • The way Universal Callback Server calculates statistics and reports them to Stat Server has been enhanced. Now Universal Callback Server uses Java extensions for statistics calculations and passes them to Stat Server.

Corrections and Modifications

This release also includes the following corrections and modifications that were made between Release 7.0.1 and the initial 7.1 release:

Universal Callback Server is now capable able to process correctly the following call flow:

  • As a result of callback request processing, an outbound call is originated from the Queue (CDN) via RequestMakePredictiveCall.
  • Answering Machine is detected by the switch.
  • As a treatment to the call result Answering Machine, a call is transferred to another CDN.
  • It is possible that the call is transferred or routed further, out of the DNs which are monitored by Universal Callbck Server.
  • Now Universal Callback Server will update the database with the correct call result (Answering Machine) and callback status (Final). (ER# 94805)

Universal Callback Server exited abnormally when the obsolete option vq was configured in the Routing Point DN, and when the value of that option contained the name of the Virtual Queue used in the Target selection block of the routing strategy that distributed virtual calls. This problem has been solved.
(ER# 92018)

If the Black List table was configured (via vcb_black_list Table Access object), but the table did not exist in the database, Universal Callback Server created this table. However, after this table was created and until either dnc_refresh_interval timeout elapsed and the Black List table was read again by Universal Callback Server or Universal Callback Server was restarted (whichever came first), all requests for the callback were denied with an error message, "Contact in the Black List." This problem has been solved. (ER# 88473)

Universal Callback Server did not process callback records retrieved from the database on startup if, at the moment of callback record retrieval, the Black List was not ready (that is, some Black List entries had not been retrieved yet from the database). As a result of this, Universal Callback Server lost track of some callback requests which were not finalized on the previous run of Universal Callback Server. Such requests remained in pending status in the database. This problem has been solved. (ER# 87665)

When running on an AIX operating system, Universal Callback Server terminated abnormally after keystroke CTRL+C had been pressed. This problem has been solved. (ER# 87436)

If Universal Callback Server was restarted while the callback request was being processed and before it reached an agent, the data that had been attached to the live call which initiated the callback request (for example, UserData collected on IVR) was not delivered to the agent's desktop. Only solution-specific attributes in the attached data were delivered to the agent's desktop. This problem has been solved.
( ER# 86794)

Universal Callback Server improperly processed dynamic updates of the Table Access Point configuration object. Behavior of the Universal Callback Server depended on when the update occurred. In some scenarios, this situation led to the abnormal termination of Universal Callback Server. This problem has been solved. (ER# 87048)

If values in the ewt_time field in the main database table were for some reason updated manually and contained an integer value less than the value of offset in seconds between the local Time Zone and GMT, Universal Callback Server terminated abnormally during startup. This problem has been solved.
(ER# 86797)

When Universal Callback Server was running as a Service, it did not reconnect to the Configuration Server after the host rebooted. This problem has been solved. (ER# 78543)

Top of Page

Known Issues and Recommendations

This section provides the latest information on known issues and recommendations associated with this product.


Universal Callback Server in primary mode may incorrectly switchover to backup mode in a situation where it is initially started in backup mode then switched to primary mode, and changes are made to the Universal Callback configuration object. This situation only applies when Universal Callback Server is configured to use the warm standby redundancy type in the Configuration Manager.

To avoid this behavior, it is recommended to perform option changes on a Routing Point level rather than on an application level for Universal Callback Server in primary mode.

As a workaround, if Universal Callback Server incorrectly switches to backup mode, another switchover should be performed to return it to primary mode. (ER# 68047591)

Found In: 7.1.000.22 Fixed In: 

Universal Callback Server is unable to un-register Virtual Routing Point (VRP) DNs with T-Server when performing a switchover from primary to backup mode if a link is down. As a result, Universal Callback Server may improperly switch from primary to backup mode, as the new primary server is not able to register the VRP DNs with T-Server. (ER# 65508134)
Found In: 7.1.000.22 Fixed In: 

When Daylight Savings Time is in effect in the GMT Time Zone, Universal Callback Server incorrectly processes the scheduled time for the scheduled callback requests that are submitted through the Web. Universal Callback Server erroneously counts this scheduled time to be 1 hour less than the actual time. In order for Universal Callback Server to calculate the scheduled time correctly, the following configuration modification is required:
  1. In CME under Environment\Time Zones, locate "GMT" time zone, select its properties, and uncheck the DST Observed box.
  2. Press OK button. (ER# 101106)
Found In: 7.1.000.10 Fixed In: 

In response to getstat request from WebAPI, Universal Callback Server always returns in attribute reqpos the same value as in attribute queuesize, instead of the position in queue. (ER# 100088)

Found In: 7.1.000.09 Fixed In: 

Universal Callback Server does not register an Agent's DN that is created and configured after Universal Callback Server has been started. As a result, Universal Callback Server does not properly process callbacks distributed to that DN. (ER# 98334)

Found In: 7.1.000.07 Fixed In: 

Universal Callback Server cannot correctly process the dynamic modification of the Table Access Object name in a configuration with the following conditions:

  1. Table Access Object with the name vcb_black_list is present in the configuration.
  2. Universal Callback Server, upon startup, cannot establish a connection to the database table as configured in this Table Access Object (for example, the DB-Server is not running).
  3. User dynamically changes names of Table Access Objects. That is, the user modifies the name of the Table Access Object, vcb_black_list, and then renames another Table Access Object as vcb_black_list. (ER# 98309)
Found In: 7.1.000.07 Fixed In: 

After installation, the Command Line Arguments parameter in Universal Callback Server Application object begins with the expression LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH. If LD_LIBRARY_PATH variable is not defined in the user environment, then the expression should be modified like this: LD_LIBRARY_PATH=. (The actual environment variable name depends on specific platform). (ER# 97290)

Found In: 7.1.000.07 Fixed In: 

When the option use_agentid is set to true, Universal Routing Server (URS) puts the AgentID instead of the DN Number into the AttributeExtensions, key DN in RequestRouteCall. Universal Callback Server interprets this AgentId as a DN, and either sends the callback to DN = AgentID (if such DN exists) or to the default DN (if default DN is configured), or marks the callback request as an error in the database if no default DN is configured. Workaround: Set the option use_agentid to false and translate the DN number into the AgentID by using:

SetTranslationOverride [","[AGENT.LOGIN]',",RouteTypeUnknown,",","].
(ER# 83373)

Found In: 6.5.000.22 Fixed In: 

In certain situations and depending on the T-Server, Universal Callback Server cannot properly process the callback request in preview mode. These T-Servers include:

  • Aspect T-Server—Universal Routing Server (URS) uses Agent IDs rather than DN in the TRouteCall destination parameter. Since Universal Callback Server requires the DN from URS upon callback request distribution, Universal Callback Server cannot properly process the callback request.

  • Alcatel A4400 T-Server—If the agent-substitute option is set to false, Universal Callback Server does not properly process the callback request. To avoid this, follow Genesys' recommendations described in the "Agent Substitution" section of the Framework 7.1 T-Server for Alcatel A4400/OXE Deployment Guide.

  • Spectrum T-Server—To avoid the processing difficulty for this T-Server, see Genesys' recommendations described in the "Dialing Capabilities" section of the Framework 7.1 T-Server for Spectrum Deployment Guide. (ER# 71833)
Found In: 7.1.000.09 Fixed In: 7.1.000.17

In an IVR-behind-the-switch configuration, after the IVR offers the callback option to the customer and gathers the required user data, the call is transferred to a Routing Point for confirmation of callback acceptance by Universal Callback Server and then returned to the IVR. If the inbound traffic is high, a customer might have to wait for an IVR port to become available for the confirmation announcement from the IVR to the customer. (ER# 80814)

Found In: 6.5.000.20 Fixed In: 

The real call and the virtual call for an ASAP callback request exist simultaneously. If a caller selects the ASAP option, Universal Callback Server creates a virtual call immediately after it receives an EventRouteRequest with attached data representing a callback request submission. The real call still exists during the time required to confirm that Universal Callback Server has accepted the callback request. Under exceptional conditions (described below), the co-existence of these two call types can cause one of these problems:

  1. If the routing strategies for both the initial inbound call and the callback request use the same Virtual Queue associated with a physical Routing Point, then two entries on the Virtual Queue exist for one transaction. The statistics for the quantity of calls in that Queue will be incorrect.

  2. When an Agent becomes available, the real call can be accidentally routed to, and completed by, that Agent, while the virtual call (callback request) is being processed as usual. A second response to the initial call may result due to a highly unusual coincidence, namely that the queue for live incoming calls becomes empty (for example, when many agents log in simultaneously) at the same moment that Universal Callback Server receives the callback request. Normally, this situation cannot occur for two reasons: (1) The IVR normally does not offer the callback option to customers when the estimated waiting time (EWT) is low, that is, when only a few calls or no calls are waiting for an available agent, and (2) a new inbound call is usually not put ahead of other calls already waiting in the same queue. (ER# 80815)
Found In: 6.5.000.20 Fixed In: 

The configuration that allows the virtual call to retain the same position in the queue that the original inbound call held, requires sending the inbound call to a termination DN (term_dn) instead of back to the IVR. In this configuration, the IVR does not inform the caller that the callback request has been successfully submitted. (ER# 80813)

Found In: 6.5.000.20 Fixed In: 

Top of Page

Internationalization

Information in this section is included for international customers.

There are no issues that affect internationalization. 

Top of Page

Additional Information

Additional information on Genesys Telecommunications Laboratories, Inc. is available on our Technical Support website. The following documentation also contains information about this software. Please consult the Deployment Guide first.

  • Voice Callback 7.1  Deployment Guide , which provides an overview of the product and its architecture, offers deployment-planning guidelines, and explains how to configure, install, start, and stop Voice Callback. 

  • Voice Callback 7.1 Reference Guide provides detailed information about Voice Callback 7.1 to facilitate deployment of this product.

  • Genesys 7 Migration Guide contains a documented migration strategy for each software release. Please refer to the applicable portion of this guide or contact Genesys Technical Support for additional information.

Top of Page