Release Note

Contents

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 Ericsson MD110.

• 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 Environment 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.
• You can find information about changes and corrections to functionality common to all T-Servers in the release note for T-Server Common Part release 8.0.x.
• Your T-Server’s name correlates generally with the name of the switch you intend to use, but vendor switch names often change. For full details on the name(s) of the switch intended for use with this T-Server, see the Genesys Supported Media Interfaces Reference Manual.

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.

Supported Operating Systems

New in This Release

This release of T-Server is built with the T-Server Common Part (TSCP) release number 8.0.101.09. 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.

There are no restrictions for this release. This section describes new features that were introduced in this release of T-Server for Ericsson MD110.

• T-Server now supports routing from devices that are configured as a Routing Queue in Configuration Manager in the same way as a Routing Point. (ER# 245565594)

Corrections and Modifications

This release includes the following corrections and modifications:

T-Server now correctly handles a PBX reject for a RequestStopMonitor request. Previously, a failure to perform a Stop Monitor may have caused T-Server to become unstable when a new Monitor was started after Stop Monitor failure. (ER# 255370706, 260531875, 253334672, 241654183)

T-Server now properly handles scenarios where a Mute Transfer from a VTO port fails. Previously, T-Server may have failed in such scenarios. (ER# 250579563)

T-Server now correctly distributes an EventDNBackInService event for all devices in a scenario where a partial PBX failure causes T-Server to receives a Stop Monitor for certain devices, and at the same time, a Sart Monitor is performed. (ER# 243283111)

T-Server now ignores a manually initiated call which contains data from a previous call that had been initiated using CTI (Agent Desktop), and has not received call progress events. (ER# 242393254)

Top of Page

Supported Operating Systems

New in This Release

This release of T-Server is built with the T-Server Common Part (TSCP) release number 8.0.001.17. 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.

There are no restrictions for this release. This section describes new features that were introduced in this release of T-Server for Ericsson MD110.

• Support for Aastra (formerly Ericsson) MX-ONE version 4.0 is announced in this release.

Corrections and Modifications

There are no corrections and modifications in this release of T-Server for Ericsson MD110.

Top of Page

Supported Operating Systems

New in This Release

This release of T-Server is built with the T-Server Common Part (TSCP) release number 8.0.001.15. 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.

There are no restrictions for this release. This section describes new features that were introduced in the initial 8.0 release of T-Server for Ericsson MD110.

• Support for call type prediction: On occasions when the CTI information is either insufficient or arrives too late for T-Server to assign a definite call type, T‑Server can now use a call type prediction procedure to assign a call type on a "best possible guess" basis.

• Support for call release tracking: T-Server now provides information about which party initiated the release of a call. This can be valuable for different applications to provide historical and real-time call reporting. This can be configured using the new configuration option releasing-party-report.

• Support for failed route notification: T-Server now supports alarm messages for unsuccessful routing scenarios.

• Support for link bandwidth monitoring: T-Server now provides bandwidth monitoring on a CTI link and can notify the Genesys Management Layer when Configuration Layer limits are exceeded.

• Support for enhanced request handling: T-Server introduces two major new enhancements to queue handling: request conflict resolution and a new device queue.

• Enhancements to emulated agent functionality: The Emulated Agent feature has a number of enhancements, including:

  • Agent logout on client unregistering from a DN.
  • Changes to legal guard processing.
  • The addition of password functionality to agent-strict-id.
  • Synchronization of emulated after call work (ACW) for emulated agents.

• Enhancements to business call processing: A new configuration option, agent-only-private-calls, enables you to specify whether calls distributed from a device are considered as private or business calls.

• Improvements to T-Server logging performance have been implemented.

• Support for new operating systems: The following new operating systems are supported:

  • IBM AIX 64-bit version 6.1.
  • HP-UX/PA 64-bit version 11i v3.
  • Red Hat Enterprise Linux AS Edition on 32-bit Intel platforms, version 5.0.
  • Windows 2008.
  • VMWare.
  • Sun Solaris Containers.
  • IBM PowerVM LPAR.

Corrections and Modifications

There are no corrections and modifications in this 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.

In a scenario where an agent does not answer a call that has arrived through an ACD Queue, and the PBX ACD Queue timeout expires, the PBX reports the call as delivered back to the ACD Queue with an incorrect CrossRefId. Therefore, T-Server cannot report an EventQueued after a call is delivered back to an ACD Queue. (ER# 266512355)

When an agent has immediate call forward set to a CTI Group, and a call is made to the agent, T-Server reports an incorrect CallState of Ok on the CTI Group. The reason for this is that for the CTI Group, the PBX incorrectly reports a cause of redirected instead of a cause of CallForwardAlways, which is reported on the originator.

The cause that is reported on a CTI Group should be the same as the cause on the originator (CallForwardAlways). In the scenario above, T-Server cannot use the cause for Reporting since the cause on the originator and on the CTI Group are different. (ER# 267335717)

MX-ONE: The switch does not report the Cause CallForwardNoAnswer in the following scenario:

The redistr-dly option is set to 2000.

1. A Predictive Call is made to ACD Queue1 on the MX-ONE switch using an ISDN Trunk to an MD110 switch.
2. The call is answered on Destination ODN1 on the MD110 switch.
3. The call is delivered to an agent on ADN1.
4. The call is not answered by the agent on ADN1.
5. The call is redistributed to the ACD Queue and is delivered the another agent on ADN2.

The switch does not report the Cause CallForwardNoAnswer message on the first agent when the ACD Queue redistributes the call to another agent. This causes T-Server to generates the new call to another agent with a new ConnID.

(ER# 232394572)

MX-ONE: An incorrect ConnID is generated on EventRinging for a destination DN on an internal call, and the switch reuses the Call ID from an outbound call for an inbound call in the following scenario:

The cast-type option is set to route.
The event-propagation option is set to list.
The consult-user-data option is set to separate.
The use-data-from option is set to consult-user-data.

1. A call is made from an agent on ODN1 on an MX-ONE switch, to ODN2 on a MD110 switch.
2. A RequestInitiateTransfer is made from the agent on ODN2 to a native Routing Point (divert from the Queue) through ISCC.
3. A RequestCompleteTransfer is performed by the agent on ODN2.
4. The call is routed by the native Routing Point to the agent on DN1.

T-Server generates an incorrect ConnID for EventRinging on DN1, and T-Server generates a call state of Redirected on DN1 instead of Ok because the switch reuses the Call ID from the outbound call (made through the outbound Trunk) for the inbound call (from the incoming Trunk).

(ER# 229341751)

MX-ONE: When setting an Absence code on an IP Phone (via RequestDNDOn), the request times out because there is no reporting from the switch. (ER# 243481471)

MX-ONE: The PBX does not report a call forwarded set on a SIP devicein the following scenario:

1. A RequestCallForwardSet is made from SIP Device1 to SIP Device2.
2. The PBX does not report that call forward is set on the SIP Device.
3. SIP Device3 makes call to SIP Device1.
4. The call is forwarded to SIP Device2.

(ER# 234796310)

MX-ONE: A call remains stuck on a consultation controller after a blind transfer and a transfer to another DN. See the following scenario for an example:

1. An agent on SIP DN1 makes a call to an agent on SIP DN2.
2. The agent on SIP DN2 answers the call.
3. The agent on SIP DN2 performs a RequestInitiateTransfer to SIP DN3.
4. The agent on SIP DN2 performs a RequestCompleteTransfer.
5. The agent on SIP DN3 answers the call.
6. The agent on SIP DN3 performs a RequestSingleStepTransfer (or other transfer types where the PBX completes the call before the destination answers) to SIP DN4.

After the final call transfer, the call still remains on SIP DN3

(ER# 234796335)

MX-ONE: Supervised routing of a call to a DN does not work if the call is made from a SIP DN in the following scenario:

The supervised-route-timeout option is set to 5.

1. An agent on SIP DN1 calls the Hunt Group (Emulated Routing Point).
2. The Hunt Group (Emulated Routing Point) performs a supervised route of the call to ODN1.

The CSTA error: systemResourceErrors : generic is received.

(ER# 234796352)

MX-ONE: In the following scenario, parties are dropped when a VoIP conference controller attempts to reconnect a failed blind transfer:

The agent is the VoIP DN conference controller.

1. A blind transfer of a conference call is made from a VoIP agent to an internal DN.
2. The VoIP conference controller does a reconnect on the call.

(ER# 211241465)

MX-ONE: An unexpected transfer event occurs in the following scenario:

1. An outbound call is made from an agent on ODN1 on MX-ONE to an agent ODN, on MD110 (ISDN).
2. The agent on ODN answers the call.
3. The agent on ODN1 initiates a consultation call to a Hunt Group with an available member.
4. The call arrives at the Hunt Group member.
5. The agent on ODN1 completes the call transfer.

The application link issues two transfer complete events. The first event has the correct attributes, but the second event has the transferring device as the external party which is incorrect.

(ER# 210098061)

MX-ONE: T-Server generates an incorrect EventAbandoned instead of an EventReleased on an ADN in the following scenario:

1. An agent on ODN1 makes an outbound call to external DN1.
2. External DN1 answers the call.
3. The agent on ODN1 does an initiate transfer of the call to ACD Queue2 (ADN2)
4. The agent on ODN1 does a complete transfer of the call.
5. The agent on ADN2 answers the call
6. The agent on ADN2 does a mute transfer to emulated Routing Point1
7. Emulated Routing Point1 routes the call to emulated Routing Point2
8. Emulated Routing Point2 routes the call to ACD Queue3 (ADN3)
9. External DN1 releases the call

T-Server generates an incorrect EventAbandoned instead of EventReleased on ADN3 with a call state of Forwarded.

(ER# 243487529)

MX-ONE: T-Server generates an incorrect releasing party in the following scenario:

1. An agent on ODN1 calls ACD Queue1.
2. The agent on ADN1 answers the call.
3. The agent on ADN1 does a consultation call to the agent on ODN2.
4. The agent on ODN2 answers the call.
5. The agent on ODN1 completes the call transfer.
6. The agent on ODN2 releases from the call.

T-Server generates ReleasingParty:1 Local instead of 2 Remote on ODN1.

(ER# 243723721)

MX-ONE: T-Server generates incorrect call state of Forwarded instead of Ok in the EventAbandoned on the Emulated Routing Point in the following scenario:

1. An agent on DN1 makes an internal call to an emulated Routing Point.
2. The emulated Routing Point does a supervised route to an ACD Queue.
3. The supervised route timeout expires.
4. The agent on DN1 releases the call.

(ER# 243487697)

MX-ONE: The release call on ADN1 is not reported in the following scenario:

1. An agent on ODN1 makes a call to the ACD Queue (ADN1).
2. The agent on ADN1 answers the call.
3. The agent on ADN1 does a mute transfer to an external DN.

(ER# 243516834)

Beginning with release 8.0, T-Server has an improved CTI request pacing mechanism, which is controlled by the new option device-rq-gap. The default value of this option is 250 milliseconds, which limits the number of requests sent to the switch to 4 requests per second on any given device.

In scenarios where a version 8.0 T-Server is used in a high-load environment, which requires higher performance, Genesys recommends setting the device-rq-gap option to a lower value at an Application level, for a global effect on all DNs, or to set the DN-level option rq-gap to a lower value for a specific high-load Routing Point DN.

Note: Setting the device-rq-gap option to a value of 0 (zero) will disable this option, resulting in the same behavior as version 7.6 and older of T-Server.

(ER# 237234829)

In a scenarios where the switch may stop monitoring some of the DNs (only part of the monitored DNs receives a StopMonitor from the switch), T-Server may change a set of DNs to the OutOfService mode, and doesen't bring them back to service. (ER# 243283111)

T-Server may reuse the TMakeCall request properies for the next call in the following scenario:

1. An agent makes an outbound call (EventOffHook), but the dialled number is not in service, and T-Server never generates Eventnetworkreached and EventDialing events.
2. The agent releases call (EventOnHook).
3. The agent makes a new outbound call using the handset (manual call).
4. The new call contains the attached user data from the first call.

(ER# 242393254)

The MX-ONE PBX only supports one distribution method to Hunt Group members:

Sequential Searching - Linear Hunt Group, where a new call always goes to member Number1, if free. If Number1 is busy, then it goes to Number2, if Number1 and Number2 are busy, then it goes to Number3.

(ER# 230165672)

The following is a statement from Aastra (previously Ericsson):

In order to maintain the same call ID during a whole Call Deflect scenario, every involved device, including logical devices such as ACD groups, must be monitored. For example, if a PBX group is involved in the deflect scenario, the Call ID may change because PBX groups cannot be monitored.

Regarding Genesys:

In Genesys, this will cause problems in some Emulated Routing scenarios, as Hunt Groups cannot be monitored. Therefore, T-Server may not be able to maintain the Call ID and, as a result, attached data will be lost. (ER# 71793929)

MX-ONE: An unexpected extra transfer event from the Application Link/switch causes an unexpected EventPartyChanged on the transfer destination in the following scenario:

1. An outbound call from MX-ONE is made to an external device which answers.
2. The outbound originator makes an emulated single-step transfer to an internal queue.
3. The call is delivered to an ADN.

(ER# 195627900)

MX-ONE: The switch does not support treatments. (ER# 211241912)

MX-ONE: The switch does not support call parking. Hold call functionality is used instead. (ER# 211241748)

MX-ONE: The switch does not provide the relevant CTI events across the link to support the Intrude feature. (ER# 211241776)

MX-ONE: Four-party conferences are not supported via CTI, but can be created manually via the handset. (ER# 211241969)

MX-ONE: The lock/unlock status of ODN-only devices is not reported by the Application Link at monitor start. Therefore T-Server reports the status of these devices as unknown. (ER# 211241884)

MX-ONE: Consultation calls are always made from the ODN. If the primary call is on ODN, then the consultation call is made from the same ODN.

If the primary call is on an ADN, then the consultation call is made from the associated ODN. (ER# 211242017)

MX-ONE: Reporting of conference events from the Application Link is incomplete when a conference party is unmonitored. When devices are released, they have different Call IDs. (ER# 211241411)

MX-ONE: Application Link reports In/Out of Service events when VoIP agents log in manually. Only emulated agents are supported by T-Server with these devices.  (ER# 211242119)

MX-ONE: The destination for Forward On Busy and Forward On No Answer cannot be dynamically set via CTI. (ER# 211242054, 211242081)

MX-ONE: It is not possible to redirect or route a call to a DN which has Immediate Forwarding set. (ER# 211242156)

MX-ONE:  When there is a call on an ADN and another call on the ODN, the request TAlternate has to be made from the active call leg, because this is the only way to populate a Reference ID on the correct event. (ER# 211242203)

MX-ONE: To complete a conference, when the conference initiator is an ADN, it is necessary to alternate the primary and consult call, so that the primary call becomes the active call (primary call on ADN), and then complete the conference. The one exception to this rule is when the primary call is Outbound. In this situation it is possible to complete the conference without alternating the call. However, the call that remains after conference completion is the consultation call that was on the ODN - the primary call on the ADN will be released. (ER# 211242285)

MX-ONE: The Application Link does not report conference calls when queried after the switch link disconnects and then reconnects. (ER# 211076244)

Emulated Redirect from an ADN or an analog device is not supported. T-Server will attempt to use a native redirect with these devices. (ER# 60333842, 60333836)

A call's position in queue is cleared when one party places the call on Hold. In addition, an Initiate Transfer also clears the position. See the Maintain Position in Queue section of the Deployment Guide for more details. (ER# 45841606, 50549339)

An incompatibility exists between T-Server and URS when T-Server option call-retain-in-queue is set to keep and the Maintain Position in Queue feature is enabled (see the Deployment Guide).

Any time an attempt is made to transfer a call back to the Routing Point, the request fails. This prevents the keep value being useful for the following scenarios:

• transfer-to-agent = false
• Multiple treatments when the call has to be returned by URS back to the Routing Point
• IVR making a transfer back to a Routing Point

(ER# 49581107)

The MD110 switch does not support a native RequestClearCall. It is only supported within T-Server when used in conjunction with the Maintain Position in Queue feature to drop a call completely. (ER# 50549313)

Conference reporting is unreliable when used in conjunction with the Maintain Position in Queue feature. (ER# 45841618)

The Application Link does not report conference calls when queried after the switch link disconnects and then reconnects. (ER# 40142095)