Release Note

T-Server for Cisco UCCE

8.0.x

Genesys Telecommunications Laboratories, Inc. © 2010

Contents

Introduction

Release Number AIX HP-UX Linux Solaris Tru64 UNIX Windows
8.0.001.00 [04/30/10] – General (Under Shipping Control) X X X X X X

Known Issues and Recommendations
Discontinued Support
Internationalization
Additional Information


Introduction

As of February 1, 2012, Genesys is no longer an affiliate of Alcatel-Lucent; any indication of such affiliation within Genesys products or packaging is no longer applicable. Please see the Genesys website at http://www.genesyslab.com for more details.

This release note applies to all 8.0 releases of T-Server for Cisco UCCE.

Use of Third-Party Software

Genesys follows applicable third-party redistribution policies to the extent that Genesys solutions utilize functionality of commercial or non-commercial third parties. For specific information on any third-party software used in this product, see the Read Me.


Release Number 8.0.001.00 [04/30/10] – General (Under Shipping Control)

Supported Operating Systems
New in This Release
Corrections and Modifications

Supported Operating Systems

The operating systems supported by this release are listed in the Contents, above.

New in This Release

This release of T-Server is built with the T-Server Common Part (TSCP) release number 8.0.001.19. TSCP is the shared software that all T-Servers use. Consult the TSCP release note for information on changes to the Common Part that may affect the functionality of your particular type of T-Server.

This release is under shipping control. This section describes new features that were introduced in the initial 8.0 release of T-Server for Cisco UCCE.

Corrections and Modifications

There are no corrections and modifications in the initial 8.0 release.

Top of Page


Known Issues and Recommendations

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


The installation of T-Server using the Wizard is not supported for this release. (ER# 251238428)

Found In: 8.0.001.00 Fixed In: 

T-Server does not react correctly to SYSTEM_EVENT messages from the switch, which causes issues.

Example: The Peripheral Gateway service stops, and the switch sends a SYSTEM_EVENT message to notify T-Server. After this, T-Server will not invoke a disconnect/reconnect procedure. Therefore, any calls established when the Peripheral Gateway is restored, will not be visible to T-Server, and T-Server will no longer be synchronized with the phones.

(ER# 251238081)

Found In: 8.0.001.00 Fixed In: 

In the following scenario:

  1. An ISCC call is made from one UCCE switch to a second UCCE switch.
  2. A RequestSingleStepTransfer is then issued to a third UCCE switch with no ISCC involved.

On receiving the transferred event from the switch, no ISCCEventPartyChanged is distributed to the origination device on the first UCCE switch.

(ER# 248305481)

Found In: 8.0.001.00 Fixed In: 

CTI-Server/OPC retains which client last controlled it. If you stop that last client, the OPC sets all the agents under the control of that server to a NotReady state.

For this reason, if the primary T-Server is stopped, and the backup T-Server becomes primary, the switch will set all idle agents to NotReady, and any agents on calls will be set to NotReady once they are idle. The only agents the switch will not place into a NotReady state are those agents already in a NotReady state.

The same behavior occurs during switchover, and the backup T-Server is stopped. For this reason, rolling upgrades cannot be supported.

(ER# 249521151)

Found In: Cisco UCCE 8.0(1) ES4 Fixed In: 

The Cisco UCCE switch does not report connection cleared when an external party releases from a conference. Therefore, no EventPartyDeleted is reported when the external party releases. In addition, T-Server will consider the call between the two remaining internal parties to be a conference call, and report the appropriate Call States and DN Roles. An EventPartyDeleted for the external party will only be distributed when the call between the remaining two parties is released. (ER# 241857151)

Found In: Cisco UCCE 8.0(1) ES4 Fixed In: 

In the following scenario, when the call is delivered to Agent2, the switch is incorrectly reporting an CALL_HELD_EVENT event for the existing call and reporting that a new call, with a new Call ID, is delivered to Agent2:

Agent1 is logged in to ACDQueue1 and is not ready.
Agent2 is logged in to ACDQueue2 and is not ready.

  1. An inbound call is received on DN1.
  2. DN1 makes a blind conference call to ACDQueue1.
  3. Agent1 becomes ready, and the call is delivered to Agent1.
  4. Agent1 makes a blind transfer to ACDQueue2.
  5. Agent2 becomes ready.

If Agent2 answers the call, the switch reports the CALL_ESTABLISHED_EVENT event on the call from the leg that is incorrectly held.

(ER# 243690676)

Found In: Cisco UCCE 8.0(1) ES4 Fixed In: 

Releasing an inbound ringing call is rejected by the switch. This issue does not affect internal calls. (ER# 245019501)

Found In: Cisco UCCE 8.0(1) ES4 Fixed In: 

The switch provides no information to T-Server about the service state of the phones. Therefore, T-Server is unable to generate EventDNOutOfService or EventDNBackInService if a phone is unplugged or loses network connectivity. (ER# 245633343)

Found In: Cisco UCCE 8.0(1) ES4 Fixed In: 

The switch reports the release of a local connection before the remote connection. For this reason, T-Server is unable to determine the releasing device for the first event. Therefore, if an external party releases first, T-Server will always report the extension ReleasingParty as Unknown. (ER# 245601836)

Found In: Cisco UCCE 8.0(1) ES4 Fixed In: 

It is possible to configure a Routing Point on the switch so that it overflows calls to agents in skill groups on different Peripheral Gateways. In such instances, the switch will provide router keys to both Peripheral Gateways in order to match the calls. These router keys can be used by the Geneys Call Overflow (COF) feature by setting the cof-enable option to a value of true, and not specifying any values in the ISCC Call Overflow Parameters of the Access Code. In such instances, Genesys will map the router keys to a network Call ID in order to match the call.

However, the use of this method to match calls requires that a call, either a direct call or a consultation call, be made to the specific Routing Point where the overflow is configured. Direct calls between agents, or any other distribution device in different Peripheral Gateways will result in the switch not providing the router calls, therefore the COF network Call ID matching will fail.

As a result of this, a cast-type of direct-network-call-id is not supported.

COF using ANI matching works as documented and is not affected by these restrictions.

(ER# 250157707)

Found In: Cisco UCCE 8.0(1) ES4 Fixed In: 

The switch does not provide queued and dequeued events when a call is made to a queue and immediately distributed to an agent. As a result, T-Server relies on the switch to report the queue as LastRedirectDeviceID when the call is delivered to an agent. From this information, T-Server can generate EventQueued and EventDiverted.

However, when a RequestMuteTransfer is made to a queue with available agents, the switch does not report LastRedirectDeviceID in the delivered event. Therefore, T-Server is not able to generate EventQueued and EventDiverted for such scenarios.

(ER# 243827738)

Found In: Cisco UCCE 8.0(1) ES4 Fixed In: 

When making a mute transfer to an external device, the switch does not distribute a network reached message. (ER# 244435724)

Found In: Cisco UCCE 8.0(1) ES4 Fixed In: 

In the following scenario, when the route destination answers, the switch reports that it is established with the device that issued the single-step transfer, which really has left the call.

  1. An outbound call is made, and is established.
  2. The call is single-step transferred to a Routing Point.
  3. The call is routed to an internal device.

Note: This issue only occurs if the initial leg is outbound.

(ER# 246083155)

Found In: Cisco UCCE 8.0(1) ES4 Fixed In: 

There are two instances where the switch will remove user-to-user information (UUI) data from a call:

  1. If a device makes an outbound call with UUI data in the RequestMakeCall request, the switch will first attach the UUI data and then remove it.
  2. If UUI data is attached on a consultation call, the switch will first attach the UUI data and then remove it.

(ER# 245028471)

Found In: Cisco UCCE 8.0(1) ES4 Fixed In: 

When an inbound call is made to a Routing Point and the external party releases, no reporting is provided by the switch. For this reason, the call remains stuck on the Routing Point. (ER# 246083213)

Found In: Cisco UCCE 8.0(1) ES4 Fixed In: 

Switch Routing Points, controlled by Genesys for routing, can either be configured as Dialed Number Plan (DNP) Routing Points, or CCM Routing Points. If using DNP Routing Points, there are two issues with mute transfer, considering that mute transfer is native, and the switch completes the transfer, not T-Server:

  1. The switch does not report events for the consultation call, and does not complete the transfer until after the call is routed.
  2. If the call times out, and it is overflowed by the switch, no route_end message is sent to T-Server, which results in a call becoming stuck on the Routing Point.

As a consequence, it is recommended that RequestMuteTransfer not be used with DNP Routing Points.

(ER# 250957781)

Found In: Cisco UCCE 8.0(1) ES4 Fixed In: 

When T-Server sends RouteCall/Reject, the switch does not report events on the Routing Point when it diverts the call from the Routing Point. As a workaround, T-Server reports the divert as soon as it sends a RouteCall/Reject. This will cause the wait time statistics on the Routing Point to be incorrect. (ER# 243923216)

Found In: Cisco UCCE 8.0(1) ES4 Fixed In: 

When making a consultation call with call data attached to the transfer and conference requests, the sequence of events returned by the switch can be different, which affects whether T-Server can report EventAttachedDataChanged.

If the switch returns CALL_DATA_UPDATE before the CALL_ORIGINATED, T-Server will generate an EventAttachedDataChanged event.
If the switch returns CALL_DATA_UPDATE after CALL_ORIGINATED, there will not be an EventAttachedDataChanged event.

(ER# 251448716)

Found In: Cisco UCCE 8.0(1) ES4 Fixed In: 

If T-Server loses link connection to the switch, once the link is reconnected, the switch provides no details for existing calls in responses to T-Server's snapshot requests. Therefore, T-Server has no information concerning all existing calls.

This issue also applies for spatial redundancy scenarios as there is a brief disconnection period while T-Server moves from one link to another.

(ER# 251475225)

Found In: Cisco UCCE 8.0(1) ES4 Fixed In: 

Reporting information received from the switch, in scenarios when switch ring on no answer (RONA) is invoked, or if the CFwdAll (Call Forward All) feature is invoked on the phone, has the following affects on T-Server reporting:

(ER# 251475377)

Found In: Cisco UCCE 8.0(1) ES4 Fixed In: 

Top of Page


Discontinued Support

This section documents features that are no longer supported in this software.


There are no discontinued features or functions for this product.


Top of Page


Internationalization

Information in this section is included for international customers.


There are no known restrictions specific to international customers.


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.

Top of Page