Release Note

Top of Page

Supported Operating Systems

New in This Release

Corrections and Modifications

This release includes the following corrections and modifications:

This release has been built with the latest libraries. (ER# 178717081)

This release of T-Server is built with the T-Server Common Part (TSCP) release number 7.6.008.03. 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 section describes new features that were introduced in the initial 7.6 release of T-Server for Siemens HiPath 4000 CSTA III.

• Enhancement to Smart OtherDN Handling: In release 7.6, configuration option clid-withheld-name has been introduced.
  
  
  • clid-withheld-name
    Default Value: PRIVATE
    Valid Values: Any string
    Changes Take Effect: Immediately
    Defines a name that replaces a withheld CLID. If no value is entered (empty string) the withheld CLID will be displayed.
  
  
• Enhancement to No-Answer Supervision: In release 7.6, configuration option nas-indication has been introduced to enable T-Server to indicate in EventReleased whether an overflow has occurred as a result of No-Answer Supervision.
  
  
  • nas-indication
    Default Value: none
    Valid Values: none, ext, rsn
    Changes Take Effect: Immediately
    Specifies the reporting action in EventReleased when No-Answer Supervision overflows a call. With value none, no reason or extension is provided in EventReleased. With value ext, extension NO_ANSWER_TIMEOUT is supplied in EventReleased. With value rsn, reason NO_ANSWER_TIMEOUT is supplied in EventReleased.
  
  
• Enhancement to Keep-Alive: In release 7.6, the Keep-Alive feature has been enhanced to include a configurable loss-rate counter.
  
  
  • kpl-loss-rate
    Default Value: 10, 100
    Valid Values: Single integer or comma-separated pair of integers. The first value in the pair is the failure value.
    Changes Take Effect: Immediately
    Specifies how many KPL positive responses are needed to decrement either the failure or warning tolerance counter. Value 0 (zero) disables this option. Two comma-separated values means T-Server will calculate both the failure counter and the warning counter. A single value means T-Server will calculate only the failure counter. See the Deployment Guide for full details.
  
  
• Enhancements to ACW: In release 7.6:
  
  
  • A wrap-up threshold can now be applied to ACW processing.
    
    
    • wrap-up-theshhold
      Default Value: 0
      Valid Values: Any positive integer
      Changes Take Effect: Immediately
      Specifies the minimum period (in seconds) that a business call must last before emulated ACW is applied at the end of the call.
      
      
  • Emulated-agent handling of changes of party is updated to (re)calculate the ACW period only in cases where the consulted party was not considered business-related before the call was transferred.
    
    
  • The verification of agent work modes for emulated agents has been improved, especially for agent ready events. The agent work mode is now also added to agent events.
    
    
• Configuration option rtmem-divert-tout has been implemented in release 7.6.
  
  
  • rtmem-divert-tout
    Default Value: 0
    Valid Values: 0-500
    Changes Take Effect: Immediately
    Defines the length of the delay (in milliseconds) between the PBX reporting of released on an emulated Routing Point member device (switch-specific type 2) and the T-Server reporting the released event. If there is a ringing event on an alternate route member device during the delay, then the T-Server handles the event as an internal transfer. This prevents the reporting of abandoned events on the emulated Routing Point when the call moves between route member devices.
    
    
• New configuration option vto-onhook-dly has been implemented in release 7.6.
  
  
  • vto-onhook-dly
    Default Value: 1000
    Valid Values: 0-10000
    Changes Take Effect: Immediately
    Specifies the delay (in milliseconds) that T-Server applies before sending EventOnHook after transferring a call. This option is valid for all devices configured in the Configuration Layer with switch-specific type 8. This delay allows the VTO enough time to receive the EventReleased before becoming available. Value 0 disables this function.
    
    
• Unification of OtherDN content: In release 7.6, when the destination or origination party is unknown, T-Server reports the party with DN Txxxxx, where xxxxx is numeric and corresponds to a dynamic ID.

A problem of incorrectly handling device ID’s after a Call Pickup scenario that resulted in stuck calls has been resolved. EventReleased and EventOnHook are now correctly issued. (ER# 160941391)

A problem with incorrect processing of RequestPrivateService returning an Invalid attribute error has been resolved. The is_DialDigits() private service has been modified to check for both new and backward-compatible private request IDs. Handling of the OtherDN has also been improved. (ER# 165689043)

Request TDeleteFromConference has been implemented. This enables the deletion of conference members from a conference. (ER# 162834657)

Switch reporting does not provide any information about call forwarding before the call arrives at the final destination. The forwarding DN is never referred to in any  events and the event causes are always reported as single-step transfer. Consequently, T-Server cannot detect this scenario nor correct it. (ER# 206778801)

When a conference is initiated to a Routing Point and then routed to an external DN, once the conference is established, the conferenced-in party releases. In this case the PBX may not always provide the correct information to T-Server and therefore sometimes T-Server may not generate EventPartyDeleted. (ER# 172756104)

When an unmonitored device makes a transfer to a monitored device, there are three EventPartyChanged events reported, one of which has a new connection ID. This is caused by the switch reporting the unmonitored transfer in two steps, and in each step only one primary old call is reported. Therefore when the first transferred event is received, T-Server creates the missing other call and performs a partial transfer. The second event completes the transfer, and the partial transfer party and call are destroyed, leading to three EventPartyChanged events. (ER# 172146007)

In the following scenario, the PBX reports that the failed party is blocked, and no event is generated by T-Server. The Release request times out. The agent can release the blocked party using the Reconnect function.

1. The agent initiates a transfer to a busy destination.
2. The switch reports dialing and then destination busy.
3. The agent tries to release the dialing party on the transferring device.

(ER# 171703324)

T-Server incorrectly reports EventNetworkReached after a single-step transfer to an ACD Queue. (ER# 128212479)

No ThisQueue is reported after a supervised route call is returned to an emulated Routing Point and rerouted to a second agent. (ER# 128212470)

DTMF can only be attached on an outbound call. (ER# 67256051)

When QSIG Path optimization is used to transfer calls to an extension (for example, from an IVR connected to such a trunk), the PBX does not report the call delivery to the transfer destination correctly. T-Server is expecting a Delivered event but instead receives a ServiceInitiated event. This means that T-Sever cannot generate the ringing event until the call has been answered manually. (ER# 66570904)

This problem occurs due to incorrect reporting from Siemens. If DND and/or Forwarding are set, on startup, T-Server is unable to display the correct status for these features for VoIP telephones. (ER# 67187437)

A single-step transfer to an external destination produces two NetworkReached events. (ER# 32164520)

It is not possible to make a chained consult call to a queue or native Routing Point. (ER# 84098421)

The following limitations apply when dialing invalid numbers:

Make call to invalid
When an invalid destination is dialed over a trunk, in some cases T-Server generates EventDestinationBusy with a call state of SitInvalidNumber. However, on some trunk types, the PBX does not provide enough messaging to generate this.

Consult Call to invalid
On a call of type consult, the PBX does not provide enough information to generate EventDestinationBusy with a call state of SitInvalidNumber.

Route/single-step transfer/redirect to invalid
The PBX does not always provide a failed event when one of the above requests is attemped to an invalid destination via a trunk. Consequently, the operation often times out.

(ER# 76010842)

It is not possible for primary and backup T-Servers to synchronize call information when a backup T-Server starts after a call was created. In this case, call control will not be maintained by T-Server after switchover, and therefore ACW behavior cannot be predicted. (ER# 88084618)

In the scenario below, T-Server does not report the completion of the Transfer or Conference and DN1 remains in a Held state. It is not possible to retrieve the call on DN1. However it is still possible to control this call via CTI (release, transfer etc).

1. A call is established between DN1 and a secret DN which is unmonitored.
2. The secret DN makes a consult call to DN2.
3. DN2 answers.
4. The secret DN completes transfer or conference.

(ER# 105417536)

When an inbound call using Q931 trunk arrives at an extension, a CTI single-step transfer request to a QSIG trunk is rejected by CAP. Two-step transfer is not affected. (ER# 66570914)

T-Server may not always report the correct conference states and roles on the remote T-Server when a conference is created using ISCC, with Event Party Propagation activated. (ER# 105674573)

When an external call, made over a Cornet trunk, is transferred to a third site, T-Server may generate the following events on the H4000: EventHeld, EventPartyChanged and EventRetrieved. This is due to switch reporting. (ER# 105416852)

If a direct call is made to an emulated Routing Point and not routed, after a while the switch moves the call to another Hunt Group member. When this happens the switch provides a Connection Cleared event but does not tell T-Server that the call has been diverted. This means that on the emulated Routing Point, T-Server generates EventQueued and EventRouteRequest followed by an EventAbandoned and then a new EventQueued and EventRouteRequest. T-Server will retain the same ConnID unless retain-call-tout is not configured. If retain-call-tout is not set or set too low then T-Server will generate a new ConnID on the new EventQueued and EventRouteRequest. (ER# 102221966)

When an emulated predictive call is made to a wrong number, T-Server incorrectly generates an outstanding request limit exceeded error instead of EventDestinationBusy with a CallState of SitInvalidNum. This can cause OCS to mark an Outbound call as Dial Error instead of Wrong Number if emulated predictive dialing is being used. (ER# 111503330)

When using emulated predictive dialing, if T-Server drops the call because the AttributeTimeout has expired, the call state is incorrectly reported as Dropped instead of NoAnswer. This causes OCS also to mark the call as Dropped instead of NoAnswer in cases where the call_wait_connect_timeout expires. (ER# 111503143)

Shutting down a primary T-Server via SCI may cause HA to fail with Genesys Desktop. To prevent this, switch T-Server over to Backup mode before shutting it down. (ER# 111925675)

The PBX does not generate OutOfService and InService events for devices. Therefore if a device goes out of service while T-Server is running there will be no notification from the PBX, so T-Server and its clients will be unaware of this. The devices will still be seen as in-service from a Genesys point of view. This can, for example, cause issues with Routing, because Stat Server will not know that the device is unavailable, and therefore URS can potentially try to route an interaction to it.

The PBX does provide T-Server with the correct state at startup, so if a device is out of service at startup, it will be flagged as such by T-Server. However, as the PBX does not generate InService events, the device will remain out of service within Genesys until T-Server is restarted. (ER# 93644)

The One Number Service (ONS) allows two phone sets to be linked together so that if either number is dialed, both phone sets will ring. The numbers are set up so that one is Primary and one is a Slave.

This feature has the following CTI limitations:

• When either number is dialed, in CTI, only a Ringing is received on the Primary. It is therefore possible to answer the call only on the Primary via CTI.
• If one device is busy and either number is dialed, then the free device does not ring. Instead an EventDestinationBusy is received.
• It is not possible to set Call Forward from the primary to the slave and vice versa.

(ER# 71255199)

When using an emulated Routing Point as the voice transfer destination of a campaign that uses CPDServer with a digital Dialogic board, the OCS option call_transfer_type must be set to one_step. If it is set to two_step the outbound call can not be successfully transferred to an agent. (ER# 47736513)

An incorrect EventRouteRequest is generated on an ACD Queue in the following scenario:

1. DN1 makes internal call to ACD Queue, which the agent answers.
2. DN1 TInitiateTransfer to a native Routing Point.
3. DN1 TCompleteTransfer.
4. The native Routing Point routes the call to DN2, which answers.

At Step 3, T-Server generates EventRouteRequest on the ACD Queue. When the native Routing Point routes the call to DN2, the call is actually routed from the ACD Queue instead of the native Routing Point, and the call remains stuck on the native Routing Point. (ER# 79358808)

After a call is redirected externally, the PBX reports the call state on the external T-Server as Forwarded rather than OK. This also occurs if the call is redirected to a Routing Point and then routed externally. (ER# 52594028)

ISCC/COF only works with already initiated calls. Examples of call flows that T-Server is able to handle with the COF feature are:

• Calls that are routed externally from native or emulated Routing Points
• Calls that are overflowed by the PBX's ACD Overflow function.

In release 7.2, new configuration options (cof-ci-defer-create, and cof-ci-defer-delete) control the operation of COF, resolving some of the previous limitations, but the following restriction still applies:

• Any call which is transferred to the external T-Server using an emulated or native single-step transfer will be treated as a normal inbound call.

(ER# 101805,101544 )

A consult call, routed from an emulated Routing Point to a GVP port, cannot be transferred. (ER# 40762866)

It is not possible to make a transfer to an external destination using external routing with ISCC from GVP. IVR Server cannot send Location in RequestSingleStepTransfer. (ER# 40596735)

Some channels of a T1 trunk connected to a DMV Dialogic card become busy after the trunk is reconnected. Channels are released by the switch in 25-30 minutes. It is possible to release channels to idle status using the the Reset feature of the VCS Monitor tool. (ER# 40595845).

Releasing a device in Ringing state generates an EventError, because the switch reports a Diverted event instead of ConnectionCleared, and the Divert is not matched with the EventReleased. (ER# 40682589)

It is not possible to transfer a conference. It is only possible to delete oneself from the conference and not any other member of the conference. (ER# 28301052)

The PBX does not allow a recalled call to be redirected, so it is not possible to use No-Answer Supervision on calls that have been recalled. (ER# 34840571)

In some scenarios the PBX does not report the correct distribution device after a call has been transferred by its originator.

Scenario 1: DN1 makes a call to Queue 1 (or Routing Point 1). DN1 then single-step transfers to Queue 2. The events following this report the queue as Queue 1 (or Routing Point 1) and not Queue 2. However, the call is correctly transferred to Queue 2.

Scenario 2: DN1 makes a call to Queue 1 (or Routing Point 1). DN1 then single-step transfers to Routing Point 2. In this case the call is transferred to Queue 1 (or Routing Point 1) and not to Routing Point 2.

Scenario 3: DN1 makes a call to Queue 1 (or Routing Point1). DN1 then mute or blind transfers to Routing Point 2. In this case we get an EventRouteRequest on both Queue 1 (or Routing Point 1) as well as on Routing Point 2. We only get an EventQueued on Queue 1 (or Routing Point1). If the call was originally to Queue 1 then it does not get delivered from the Queue but it is possible to route it from Routing Point 2. However, an EventDiverted is not reported on Routing Point 2 and therefore a phantom call is left on the Routing Point. An EventDiverted on Queue 1 (or Routing Point 1) is received, so there is no phantom call there. (ER# 31679884)

In the following scenario, when DN1 drops the call, an EventReleased is generated on DN3 but not on DN1. Another RequestReleaseCall is required on DN1 in order to get an EventReleased. However, then the Consult call remains in a Held state on DN1 and it is not possible to do anything with it (Release/Retrieve/Reconnect) via CTI. It has to be dropped by DN2 or manually.

1. DN1 MakeCall to DN2. DN1 InitiateTransfer to DN3. DN3 AnswerCall. DN1 AlternateCall.
2. DN1 Drop active call (to DN2) using ReleaseCall.

(ER# 30533702)

When making a single-step transfer via ISCC with cast-type set to direct-ani the token used by ISCC is the orgination of the primary call and not the destination. This does not match the ANI and the remote connection fails. (ER# 74387, 55715)

The HiPath 4000 rejects TRedirectCall for calls that have already been distributed by another device (for example, Routing Point, Queue, or Hunt Group). As a consequence of this, setting the T-Server option agent-no-answer-overflow to value recall has no effect. (ER# 75637, 75639)

Chained consult calls are not supported on an analog line. Also single-step transfer of the destination of a consult call from an analog line is not supported. This affects VTO scenarios where a consult call is made to a Routing Point then routed to a VTO port. (ER# 87207, 86812).

With analog devices: