Product: IBM CallPath Enterprise Server Version: 6.3.0 Level: E2033 Platform: Windows Date: 25 June 2001 Service File: ecswnt.exe History: ecswnt.hst Size: 4645396 (4.4Mb) Installation Instructions: -------------------------- Download the self-extracting file, ecswnt.exe, into a temporary directory. Execute it from the command line and follow the prompts. This will start an InstallShield Wizard to guide you through the installation process. Fixes contained in this Service Package: ---------------------------------------- Name: APAR IC28247 Date: 6 June 2001 Library: 9430 Symptom: JTAPI behaves as if an agent is still logged on after he is logged off. However, requests on behalf of this agent fail. Problem: If on an agent logon request an ACD of X is specified, but once the logon is processed the agent is really associated with ACD Y then internal to JTAPI the agent remains associated with both ACDs. At agent log off, clean-up code does not remove the agent's association with ACD X. On a subsequent logon attempt, the agent appears to already be logged on. So, the logon request simply returns without actually logging the agent on. Solution: Once an agent logon completes, the ACD value in the agent object will be updated to the actual associated value. Updates were required to the JTAPI daemon, the JTAPI client, and CPPhone to correct this problem. Name: APAR IC30630 Date: 08 Jun 2001 Library: 9449 Symptom: If csebcp receives a "connected" event where the connecting party's connection ID matches any of the connection IDs of the existing parties, and the connecting party's connection ID was not previously seen by csebcp in another event, and there are two or more existing parties, a core dump in csebcp will occur. Problem: csebcp handles internal data structures incorrectly in this scenario. Solution: Modify csebcp to avoid core dumping and handle internal data structures correctly in this scenario. Name: APAR IC30248 Date: 8 May 2001 Library: 9399 Symptom: JTAPI daemon abnormally ends while processing a TADS_DEVICE_DATA_EVENT event. Problem: When the call associated with a device data event is no longer active, the program may use an invalid pointer in attempting to reference call data that is no longer available. Solution: Code changed to correct the problem. Name: APAR IC30261 Date: 25 Apr 2001 Library: 9401 Symptom: If csebcp gets a call on an SL1 with a Network ACD (NACD) "Call Action Provided" event with information indicating it came from a source switch, and the call arrives without data, then an application does TadsSetCallData on this call, then the call is transferred to a Network ACD, the data that we got from the TadsSetCallData for this call is not sent to the CEO csebcp server "receiving" the NACD call. Problem: csebcp does not send NACD data to other servers in this scenario. Solution: Modify csebcp to send NACD data to other servers in this scenario. Name: APAR IC30260 Date: 25 Apr 2001 Library: 9398 Symptom: If a Network ACD (NACD) configuration is not reciprocal, that is, one CEO server has NACD "turned on" and referencing another CEO server that does not have NACD configured, csebcp may core (more likely on AIX), also, csebcp may core if NACD is attempted from a source system at release 2.2.1 and a target system (with NACD "on" or "off") at release 6.2 or higher. (Both of these scenarios are unsupported operations.) Problem: csebcp handles received NACD information incorrectly, causing the core. Solution: Modify csebcp to avoid core dumping in this scenario. (Note: This change simply avoids core dumping in these scenarios. Both of the scenarios above are unsupported and NACD data transfer will not take place in either of these scenarios.) Name: APAR IC30239 Date: 25 Apr 2001 Library: 9397 Symptom: If csebcp receives a "connected" event where the connecting party's connection ID matches any of the connection IDs of the existing parties, and the connecting party's connection ID was not previously seen by csebcp in another event, a core dump in csebcp will occur. Problem: csebcp handles internal data structures incorrectly in this scenario. Solution: Modify csebcp to avoid core dumping and handle internal data structures correctly in this scenario. Name: APAR IC30198 Date: 30 Apr 2001 Library: 9388 Symptom: Occasionally a CEO API request may fail for no apparent reason. The possible error codes in this situation are TADS_FUNCTION_UNAVAIL, TADS_MODULE_UNAVAIL, or TADS_NOT_SUPPORTED. Problem: A timer tick is placed in an internal error code field and is not cleared when no longer needed. The lower order two bytes of this timer tick is subsequently treated as an error code. If this value matches a potential error code then the request may fail. Solution: The code was updated to initialize the error code to zero. Name: APAR IC30164 Date: 25 Apr 2001 Library: 9372 Symptom: If csebcp receives a "connected" event for an unmonitored party, a core dump in csebcp will occur. Problem: csebcp handles internal data structures incorrectly in this scenario. Solution: Modify csebcp to avoid core dumping and handle internal data structures correctly in this scenario. Name: APAR IC30137 Date: 19 Apr 2001 Library: 9339 Symptom: The message "Warning!, Sem already locked by this thread" appears in cplog/cperr repeatedly if resources are being heavily used (heavy call activity is in progress). Problem: csebcp internal semaphores are not unlocked correctly in cases of heavy resource usage (heavy call activity). Solution: Modify csebcp to correctly unlock internal semaphores in this situation. Name: APAR IC30121 Date: 18 Apr 2001 Library: 9353 Symptom: The application hangs or traps on a call to TadsQueryLineStatus. Problem: If the response returned to the TadsQueryLineStatus API code from CEO includes a return code of 0 but no reply data, then memory may be overwritten. Solution: The code was changed to return a non-zero return code when there's no reply data returned. Name: APAR IC30007 Date: 13 Apr 2001 Library: 9329 Symptom: You can log an agent on and make calls, but if you log the agent off then you can no longer use that agent or phone from JTAPI. Problem: The Alcatel switch uses the agent ID and agent address parameters differently than other switches. This resulted in an incorrect internal state for the agent. Solution: For an agent logon, the agent ID and agent address parameters will be swapped by the JTAPI daemon. So, in the CEO configuration the actual base phone addresses must be configured as agent IDs and the configured terminal/address will be the actual agent ID. The Alcatel switch dependent code is being updated as well to ignore unnecessary parameters passed by the JTAPI daemon. Name: APAR IC29903 Date: 05 Apr 2001 Library: 9268 Symptom: The JTAPI daemon would core dump if an agent picked up their phone set and manually dialed their own number. Problem: The rejected event processing only really handled the case when an agent dialed a different number. It did not handle any single party or error in the calling party rejected event combinations. Solution: The module handing rejected events was changed to handle all of the different types of rejected events and now correctly reports this activity to applications. Name: APAR IC29887 Date: 05 Apr 2001 Library: 9263 Symptom: A unknown exception would be returned when an unhold request was made which resulted in a TADS_INVALID_CALLID return code from a TadsRequestRetrieve issued by the JTAPI daemon. A side effect of this would be connection left for the other party in the call. Problem: The return code from the TadsRequestRetrieve was overwritten which resulted in the unknown value. Solution: The JTAPI daemon was updated to return the correct exception value and to clear the connection for the other party. Name: APAR IC29904 Date: 21 Mar 2001 Library: 9274 Symptom: Need more trace info in cplog if a TadsRequestExtend is performed and the return code (usRC) is not TADS_OK. Problem: Trace data in cplog was insufficient for TadsRequestExtend if usRC is not TADS_OK. Solution: Modify the code to print more trace information to cplog in this situation. Name: APAR IC29802 Date: 06 Mar 2001 Library: 9229 Symptom: If there are many calls older than two hours, and it takes longer than five seconds to clean them up (clean up internal data structures related to these calls), csebcp may delete the internal call model of calls that arrive during this time period of call cleanup. Problem: csebcp doesn't properly handle new calls received during old call cleanup. Solution: Code change made to csebcp to properly handle new calls received during old call cleanup. Name: APAR IC29803 Date: 06 Mar 2001 Library: 9223 Symptom: If a Transfer event arrives at csebcp from CallPath Server and another CallPath Enterprise Daemon makes certain calls to csebcp at the same time, "ERROR: Sem timeout" messages may appear in the cplog and cperr logs and any TADS_CALL_STATS_EVENT messages generated as a result of the transfer event are delayed 5 seconds. Problem: csebcp mishandles the locking and unlocking of internal lists within csebcp, resulting in the error messages and possible delay. Solution: Code change made to csebcp to handle the locking and unlocking of internal lists correctly. Name: APAR IC29791 Date: 06 Mar 2001 Library: 9233 Symptom: An SQLException is sometimes thrown when Call Reporter attempts to insert a call segment or call segment record into the database. The SQLException is for a primary key contraint violation and indicates that there is already a record in the database with the same primary key. When this happens, Reporter goes into suspend mode. Problem: There are several cases where the call unique key in a segment is set to all zeros. If this happens more than once, the second database insert fails because of a duplicate primary key. Solution: Code change made to ensure that the call unique key in a segment is always set to a non-zero value. Name: APAR IC29699 Date: 26 Feb 2001 Library: 9206 Symptom: If Network ACDs are being used, shortly after cleanup of calls more than two hours old, a core dump in csebcp may occur. Problem: csebcp incorrectly handles locks of two internal lists, resulting in a deadlock that potentially leads to a core dump. Solution: Code change made to csebcp to properly handle locking of two internal lists so core dump does not occur. Name: APAR IC29701 Date: 26 Feb 2001 Library: 9178 Symptom: Problems may occur reading items on csebcp internal lists if the lists have been corrupted, resulting in not finding calls or monitors previously put on internal lists. Problem: csebcp may have a problem reading items on internal lists if the list(s) are corrupted. Solution: Code change made to csebcp to better handle reading internal lists if the list(s) are corrupted. Name: APAR IC29702 Date: 26 Feb 2001 Library: 9162 Symptom: Many "Warning!, Sem already locked by this thread" messages appear in the cperr and cplog files. Problem: csebcp thinks that a internal list's semaphore was already locked but not unlocked by the thread now locking it when that is not correct. Solution: Code change made to csebcp to detect cases of multiple locks of internal lists by the same thread correctly. Name: APAR IC29703 Date: 26 Feb 2001 Library: 9155 Symptom: On Network ACD calls, you may see the error message "Error: Sem timeout: tmcprict.cpp, line 6090" (or a nearby line number) in the cperr and cplog files and you may also get a 5 or 10 second delay in the handling of Network ACD calls. Problem: csebcp mishandles the locking and unlocking of an internal list relating to Network ACD calls, resulting in the error message and possible delay. Solution: Code change made to csebcp to handle the Network ACD internal list correctly. Name: APAR IC29706 Date: 21 Feb 2001 Library: 9214 Symptom: When making an agent ready when operating with a Lucent G3 switch, the agent state would be reported as unknown instead of ready. Problem: The CallPath Enterprise Daemon implemented two new agent states, TADS_ACD_STATE_READY_IMPLICITY and TADS_ACD_STATE_READY_EXPLICITY, in the 6.3 release which the JTAPI daemon was mapping to the unknown states. Solution: The code was changed to map the new agent states to the ready state instead of the unknown state. Name: APAR IC29007 Date: 21 Feb 2001 Library: 9211 Symptom: Alerting or connected events where discarded in some scenarios where three or more parties where reported by the to the JTAPI Daemon. This was found when running with a Lucent G3 switch using the converse vectoring feature to route calls to a VRU. Problem: The code processing alerting and connected events incorrectly picked the calling party as the first one in the other parties list reported by the CallPath Enterprise Daemon and was unable to process the event. Further investigation uncovered a problem in the CallPath Enterprise daemon with the duplicate event feature enabled. This created may more calls with three or more parties. The error in the duplicate event feature was fixed in APAR IC29544 and is required for correct operation with the JTAPI Daemon and the Lucent G3 Converse vectoring flows. Solution: The code was changed to handle these events when the calling party appears anywhere in the list. Name: APAR IC29637 Date: 16 Feb 2001 Library: 9198 Symptom: JTAPI daemon abnormally ends on a request to get acd connections list. This occurs if the list being returned has more than 20 entries. Problem: A fixed size array was being used to build the reply to this query request. The bounds of this array was exceeded. Solution: Code changed to correct the problem. Name: APAR IC29603 Date: 14 Feb 2001 Library: 9157 Symptom: If RICT is running, and then access to the CallPath Enterprise Client from csebcp goes away and then we regain access to the client, all further TadsRequestRICTLine requests fail with return code TADS_RESOURCES_UNAVAIL. Problem: If access to the CPE client fails and then we regain access to the client, RICT stops working and TadsRequestRICTLine requests return TADS_RESOURCES_UNAVAIL. Solution: Code change made to csebcp to properly handle RICT bridge line resources during this situation, allowing RICT to work after the CallPath Enterprise Client becomes available. Name: APAR IC29606 Date: 14 Feb 2001 Library: 9143 Symptom: Depending on the timing of the TadsRequestRICTLine, it can take up to 5 minutes to timeout if the expected event has not arrived, even if the ulTimeout parameter is set to a much shorter time period (say, 30 seconds). Problem: csebcp only checks TadsRequestRICTLine requests for timeouts every 5 minutes, causing a potential 5-minute delay before the TadsRequestRICTLine request times out, even if the ulTimeout parameter is set to a much shorter period. Solution: Code change made to csebcp to, as a default, check TadsRequestRICTLine requests for timeouts (due to failure to receive the expected incoming call) every 20 seconds, which should cause timeouts to occur much closer to their expected timeout times. Name: APAR IC29571 Date: 12 Feb 2001 Library: 9181 Symptom: Under certain conditions dealing with Network ACD on the Nortel SL1 switch, a TadsSetCallData may return TADS_OWNERSHIP_ERROR return code and not set the call data. Problem: Under certain conditions dealing with Network ACD on the Nortel SL1 switch, csebcp does not set the call data when requested. Solution: Code change made to csebcp to set the call data on Network ACD scenarios on Nortel SL1. Name: APAR IC29551 Date: 07 Feb 2001 Library: 9144 Symptom: If csebcp (not an application) issues a Query Party Status (STLQPS) on its own to CallPath Server and gets a negative response, the message "WARNING: QPS Sem: rc = 0, i = 0" appears in the cperr and cplog logs. Problem: csebcp fails to let its internal thread awaiting a Query Party Status response know about it properly if it is a negative response. Solution: Code change made to csebcp to correctly handle Query Party Status negative responses when csebcp generated the Query Party Status. Name: APAR IC29544 Date: 07 Feb 2001 Library: 9176 Symptom: Under certain conditions, routed events that are supposed to go to applications monitoring for such events don't get to the applications, or too many transferred events may be generated. Problem: csebcp fails to send routed events or transferred events correctly. Solution: Code change made to csebcp to correctly send routed and transferred events to monitoring applications. Name: APAR IC29532 Date: 07 Feb 2001 Library: 9170 Symptom: TadsQueryLimitations returns values for Index switch that indicate that TadsRequestForward is supported, when in fact it is not supported on Index switch. Problem: TadsQueryLimitations returns a wrong value for the Index switch. Solution: Change made to cseblims.cfg to correctly note that TadsRequestForward is not supported on the index switch. Name: APAR IC29529 Date: 07 Feb 2001 Library: 9166 Symptom: Have a call in to an extension. Extend from that extension to another extension. Now, place a hold on that second extension then try, via TadsRequestAlternate, to alternate the calls at the first extension. It doesn't happen. Problem: If csebcp has a call in the above situation (one call appearance at the extension in held state, another one in holding state), csebcp rejects the request and does not send an Alternate Call request to CallPath Server. Solution: Code change made to csebcp to allow Alternate Call to proceed in this situation. Name: APAR IC29504 Date: 01 Feb 2001 Library: 9149 Symptom: Duplicate calls created in JTAPI daemon on Hicom 300 switch Problem: The Hicom 300 switches send a SETUP event for every MAKECALL request. The JTAPI daemon would always create a new call when a SETUP was received since a SETUP is only suppose to be sent when a call is made manaully and not as a result of an API request. Solution: To work around the extra SETUP event, the JTAPI daemon was updated to ignore a SETUP event in the case where a MAKECALL or CONSULT request was issued via the JTAPI daemon. Name: APAR IC29376 Date: 01 Feb 2001 Library: 9120 Symptom: SKBR Agents are left logged on in the JTAPI daemon if the switch link or CallPath Server goes down. Problem: The SKBR daemon implicitly logs off its agents when the switch link or CallPath Server goes down. This behavior was never implemented in the JTAPI daemon which would leave the SKBR agents logged on. The result was that manipulation of the SKBR agents would fail when the switch link or CallPath server resumed operation. Solution: The JTAPI daemon was updated to send logoff events to all of the active providers with SKBR agents when it detected a switch link or CallPath Server down condition. This will allow the clients to properly recover when service returned. Name: APAR IC29486 Date: 31 Jan 2001 Library: 8438 Symptom: On the Nortel SL1 switch, TadsQueryLineStatus may return a call that is no longer there. Problem: If csebcp receives a "call rejected" message from a Nortel SL1 switch not due to an error in the calling party (for example, if it is in the called party) CallPath Interface Daemon may not properly clean up its internal call model. Solution: Code change made to csebcp to correctly clean up its internal call model on "call rejected" messages in this situation. Name: APAR IC29388 Date: 17 Jan 2001 Library: 9119 Symptom: On Aspect CSTA switch, Network ACD processing slows down if a caller abandons while in an Network ACD queue. Problem: On Aspect CSTA switch, if a caller abandons while in an Network ACD queue, a semaphore timeout will occur of an internal semaphore within csebcp, causing csebcp event thread handling for Network ACDs to be stalled for 10 seconds. Solution: Code change made to csebcp to avoid this semaphore timeout avoid any delay in Network ACD handling in this scenario. Name: APAR IC29311 Date: 12 Jan 2001 Library: 8632 Symptom: Call model and call data may be deleted from a call on the Aspect CSTA switch in certain "immediate forwarding" situations. Problem: Under certain "immediate forwarding" situations on the Aspect CSTA switch, the internal data structures and knowledge of a call and call data are deleted while the call is still at the switch. Solution: CSEBLIMS.CFG change made to avoid losing the call model/data in these situations. Name: APAR IC29237 Date: 04 Jan 2001 Library: 9056 Symptom: Core dump occurs due to data structure corruption - connected last event seen. Problem: Under certain circumstances (seen only on Tadiran switch), when a connected event occurs, CSEBCP's internal data structures are corrupted, causing a core dump to occur in CSEBCP. Solution: Code modified to avoid core dumping in this situation. Name: APAR IY15507 Date: 03 Jan 2001 Library: 9095 Symptom: TADS_DEVICE_DATA_EVENT is received by CSEBCP from the switch but not sent on to the applications that are monitoring for this event. Problem: A code bug in CSEBCP caused TADS_DEVICE_DATA_EVENTs to not be sent to applications monitoring for this event. Solution: Code modified to correctly send the TADS_DEVICE_DATA_EVENTs to the applications that are monitoring for this event. Name: APAR IC29226 Date: 03 Jan 2001 Library: 9005 Symptom: CSEBCP "locks up" without activity occurring if internal data structures are corrupted. Problem: If internal data structures within CSEBCP are corrupted (seen only on the Tadiran switch), CSEBCP could end up "locking up" (infinite loop) when attempting to access such a data structure. Solution: Code modified to print diagnostic messages and not "lock up" in this scenario. Name: APAR IC29172 Date: 10 Dec 2000 Library: 9064 Symptom: JTAPI Daemon refuses to accept any getprovider requests Problem: The JTAPI Daemon disallows any new Java client connections to because the provider ID table filled up. This occurs after 6000 connections which is the size of the table. Solution: A problem was found in the code clearing out the provider ID table after a connection drops and has been fixed. Name: APAR IC29173 Date: 10 Dec 2000 Library: 9045 Symptom: JTAPI Daemon leaves around dead calls older than 8 hours Problem: The garbage collector code would only wake up every 8 hours which creates a situation where a call could age up to 15:59:59 before being deleted. The only way to clear this condition any sooner was to restart the daemon. Solution: The garbage collector code was updated to allow a configurable call timeout. The value appears in the [JTAPI] section in the CSEBPROF.INI file with the format CALLTIMEOUT = nnn where nnn is the number of seconds. The default value is 28800 which is eight hours. The minimum value is 300 (5 minutes) and the maximum value is 129600 (36 hours). The logic in the garbage collector now wakes up at 1/4 of the call timeout and therefore will not allow any call to stay around longer than 125% of the time out value. Name: APAR IC29174 Date: 10 Dec 2000 Library: 9045 Symptom: Need to control tracing without restarting the JTAPI Daemon Problem: The JTAPI Daemon must be restarted to change any tracing options for diagnostics. Solution: The code was changed to use configurable trace options set in the [JTAPI] section of the CSEBPROF.INI file. The format is TRACE = TRACE,DEBUG,DBVERIFY,ENCODING or TRACE = ALL. These values override the /T /D /V and /X startup options respectively. Name: APAR IC29175 Date: 10 Dec 2000 Library: 9044 Symptom: Bogus connections left after caller hangs up during xfer Problem: Bogus connections are left if the caller hangs up while the call is in the process of being transferred from an agent or VRU port to another agent or VRU port. The problem occurs because a disconnected event for the vertex of the transfer flows ahead of the negative response for the original request. The logic in the code would send back a positive response by default which is incorrect since the request was not to disconnect, but to do something else. This same situation can occur with a consult, answer, hold, conference, and alternate call request. Solution: The code was changed to correctly send back a negative response and avoid the creation of the rogue connections. Name: APAR IC29098 Date: 12 Dec 2000 Library: 9068 Symptom: TCP/IP connection between daemon and server is stopped and restarted Problem: When a daemon is trace logging to file and the system is busy, a "busy" return code from a TCP/IP send request could be interpreted as an unrecoverable error. As a result, the TCP/IP connection is closed and a new connection established. Solution: Code modified to retry a failed TCP/IP send request, regardless of the reason for failure, before bringing down the connection. Name: APAR IC28975 Date: 26 Oct 2000 Library: 9033 Symptom: Fields in TADS_CALLID_DISCONNECTED_EVENT in error between AIX and non-AIX platforms. Problem: Fields in TADS_CALLID_DISCONNECTED_EVENT are not copied properly when CSEBCP executable is running on AIX operating system, and application monitoring for event is running on non-AIX (or vice-versa). Solution: Code modified to copy fields in TADS_CALLID_DISCONNECTD_EVENT properly. Name: APAR IC28976 Date: 21 Nov 2000 Library: 9032 Symptom: Transferred event has incorrect monitored party if SendDuplicateEvents is off. Problem: If the SendDuplicateEvents parameter in csebprof.ini is set to OFF and CSEBCP is sending a transferred event for a party, that event may carry, as a monitored party, an external unmonitored party. Solution: Code modified so that if SendDuplicateEvents is off, make sure events generated in response to an Transferred event from a switch are sent to a monitored party if one is available. Name: APAR IC28932 Date: 17 Nov 2000 Library: 9028 Symptom: If a CEO client connects to a server and immediately disconnects, the server may hang. Problem: The server receives new connections on one thread and manages connections on another thread. The managing thread runs at a higher priority and in rare cases may delete a connection that is still being processed as a new connection by the other thread. Solution: Modified the source code to remove the possibility that a connection was still being referenced when deleted. Name: APAR IC28805 Date: 26 Oct 2000 Library: 8964 Symptom: Need more trace info in cplog for RICT, and NACD on SL1 switch. Problem: Trace data in cplog was insufficient for RICT or NACD on SL1 switch. Solution: Modify the code to print more trace information to cplog in these situations. Name: APAR IC28575 Date: 26 Oct 2000 Library: 8991 Symptom: Attempt to use TadsRequestHold fails for connection to Alcatel even though the switch can support it. Problem: The Alcatel section of the CSEBLIMS.CFG did not indicate the correct Call_Profile values for Hold_Call. Solution: Modify the CSEBLIMS.CFG so CSEBCP will use the correct values in the Call_Profile. Name: APAR IC28539 Date: 25 Oct 2000 Library: 8992 Symptom: G3 switch - monitors show incorrect number of calls on ACD queue. Problem: On the G3 switch, queues can be non-FIFO. Our code had done cleanup of "old" queue entries assuming the queue was FIFO, leading to incorrect data at customer monitors. Solution: Rule modified to not cleanup "old" queue entries for this switch. Name: APAR IC28502 Date: 20 Oct 2000 Library: 8971 Symptom: Core dump occurs due to data structure corruption - disconnect last event seen. Problem: Under certain circumstances (seen only on Tadiran switch), when a disconnect event occurs, CSEBCP's internal data structures are corrupted, causing a core dump to occur in CSEBCP. Solution: Code modified to avoid core dumping in this situation. Name: APAR IC28503 Date: 20 Oct 2000 Library: 8970 Symptom: Core dump occurs due to data structure corruption - routed last event seen. Problem: Under certain circumstances (seen only on Tadiran switch), when a routed event occurs, CSEBCP's internal data structures are corrupted, causing a core dump to occur in CSEBCP. Solution: Code modified to avoid core dumping in this situation. Name: APAR IC28504 Date: 20 Oct 2000 Library: 8966 Symptom: Call parked event received for an unmonitored party results in core dump. Problem: If a Call Parked event arrives for an unmonitored party, a core dump in CSEBCP will occur due to a code bug. Solution: Code modified to handle this situation correctly. Name: APAR IC28505 Date: 20 Oct 2000 Library: 8966 Symptom: Event has incorrect monitored party if SendDuplicateEvents is off. Problem: If the SendDuplicateEvents parameter in csebprof.ini is set to OFF and CSEBCP is sending an event for a party, that event may carry, as a monitored party, an external unmonitored party. Solution: Code modified so that if SendDuplicateEvents is off, make sure events generated in response to an Alternated, Conferenced, Held, Call Parked, Call Picked, or Routed event from a switch are sent to a monitored party if one is available. Name: APAR IC28331 Date: 12 Oct 2000 Library: 8960 Symptom: Event has incorrect monitored party if SendDuplicateEvents is off. Problem: If the SendDuplicateEvents parameter in csebprof.ini is set to OFF and CSEBCP is sending an event for a party, that event may carry, as a monitored party, an external unmonitored party. The problem manifested when a customer was using a predictive dialer campaign to send calls to external unmonitored parties - Skills-Based Routing didn't learn when the calls were connected and did not handle the call appropriately. Solution: Code modified so that if SendDuplicateEvents is off, make sure the TADS_ALERTING_EVENT, TADS_CONNECTED_EVENT, TADS_DISCONNECTED_EVENT, or TADS_REJECTED_EVENT is sent to a monitored party if one is available. Name: APAR IC28418 Date: 06 Oct 2000 Library: 8947 Symptom: Incorrect or missing TADS events if a call is picked. Problem: The Alcatel section of the CSEBLIMS.CFG did not indicate that CSEBCP should monitor the base server for call_picked events. Solution: Modify the CSEBLIMS.CFG so CSEBCP will monitor an Alcatel for call_picked events. Name: APAR IC28405 Date: 04 October 2000 Library: 8172 Symptom: CSEBCP occasionally core dumps when disconnecting from call. Problem: Under certain conditions (was seen on the Tadiran switch), a disconnect can cause internal CSEBCP data structures to be corrupted, resulting in a core dump. Solution: Code changed to validate data structures prior to use. Name: APAR IC28406 Date: 04 October 2000 Library: 8923 Symptom: CSEBCP occasionally core dumps when connecting to a call. Problem: Under certain conditions (was seen on the Tadiran switch), a connect can cause internal CSEBCP data structures to be corrupted, resulting in a core dump. Solution: Code changed to validate data structures prior to use. Name: APAR IC28407 Date: 04 October 2000 Library: 8942 Symptom: Disconnect event is not returned to Skills-Based Routing under certain conditions. Problem: Under certain conditions, during an outgoing campaign with Skills-Based Routing, when a predictive call is cancelled by the switch because the called party didn't answer, CSEBCP can see only a MakeCall and then a Disconnect, with no other activity on the call. This causes CSEBCP to not send the Disconnected event to Skills-Based Routing. Solution: Code changed to send the Disconnect event under these conditions. Name: APAR IC28398 Date: 04 October 2000 Library: 8902 Symptom: There is no cseblims.cfg stanza for the Index switch. Problem: Index switch cannot be configured. Solution: Stanza for cseblims.cfg added for the Index switch. Name: APAR IC28313 Date: 15 September 2000 Library: 8929 Symptom: JTAPI Daemon core dumps when sent an agent logon request Problem: For switches that do not require agent ids or pools to logon an agent, a core dump will occur when trying to issue an agent logon/logoff request. The cause was an uninitialized variable and has been fixed. Solution: None. Fix requires this code update. Name: APAR IC27946 Date: 09 September 2000 Library: 8908 Symptom: JTAPI platform exception returned from disconnect request and others Problem: The TADS_INVALID_CALLID exception can occur when an event flow incorrectly flows from CP daemon that the JTAPI does not know how to process. To be able to recover from this condition without restarting the JTAPI daemon, the disconnect request needs to be able to delete bad connections. Solution: Changed the disconnect request processing to no longer flow the TADS_INVALID_CALLID exception and synthesize the disconnect events since the CP daemon has already deleted the callid. Name: APAR IC27947 Date: 09 September 2000 Library: 8901 Symptom: A ghost connection is left after a connect request is issued from a busy calling party. Problem: When a REJECTED event with an error in the calling party is generated from CP daemon, the JTAPI daemon did not delete the connection created by the calling party. This can occur if there is a call already active from the calling party before the system starts. Solution: The JTAPI daemon was changed to delete both the calling and called connections for a call from a busy extension. The code was waiting for a disconnect request to be sent from the calling party which never flows in this case since the calling party never goes off-hook to create a connection. Name: APAR IC27945 Date: 09 September 2000 Library: 8875 Symptom: JTAPI daemon core dumps on transfer/conference event Problem: The function called MoveConnections would fail when processing a transfer/conference event. The system would core dump/trap while trying to encode a corrupted call. Solution: The JTAPI daemon was changed to discard the incomplete conference or transferred call. Applications can then either issue disconnect requests for the corrupted calls left around or ignore them and wait for them to be cleared by the internal deadcall thread within the JTAPI daemon. Name: APAR IC27703 Date: 09 September 2000 Library: 8874 Symptom: JTAPI Daemon fails to start when >200 ACDs are configured Problem: The JTAPI Daemon will fail to initialize if >200 ACDs are configured and generated numerous TadsDropApps events. The excessive TadsDropApps events will cause all of CallPath Enterprise Daemons to behave erratically or stop functioning. Solution: The JTAPI daemon was changed to increase the number of ACDs from 200 to 4000. The initialization method no longer fails if too many extensions or ACDs are configured. The JTAPI daemon just discards the extra entries and logs them as missing. Name: APAR IC27811 Date: 25 August 2000 Library: 7916 Symptom: Under certain conditions, diagnostic reporting can cause CP Daemon to trap. Problem: In certain operating environments, the generation of CP Daemon diagnostic messages can cause CP Daemon to trap. Solution: Code modified to handle diagnostics correctly in case of null pointers or null objects. Name: APAR IY12500 Date: 17 August 2000 Library: 8882 Symptom: Connections to a CallPath Enterprise server are refused. Problem: A couple of limits are reached once the number of TCP socket connections to a AIX CallPath Enterprise server (CSEBSERV) nears 2000. The first limit reached is the number of open files allowed per AIX process. The default open file limit is 2000. This limit can only be changed in AIX 4.3.1 or later. To change this value for the user that's running CSEBSERV, use the command "chuser nofiles= ". The next limit reached is the number of TCP socket connections allowed by CSEBSERV. This limit is being increased by this APAR. Solution: Increased the maximum number of allowed TCP socket connections from 2048 to 8192 for AIX (from 2048 to 4096 for Windows NT). Name: APAR IC27570 Date: 25 July 2000 Library: 8766 Symptom: Events show calls with large numbers of incorrect participants and Call Reporter may crash. Problem: When a G3 switch is configured for converse vector processing and the VRU ports are monitored, the connected event received for the VRU port includes the VDN as well as the caller. This caused CSEBCP to add the VDN to another call and delete the existing call for the VRU port. Solution: Code modified to properly handle the Connected event for this situation. Name: APAR IC27407 Date: 25 July 2000 Library: 8785 Symptom: Exception in csebcp.exe while processing a TadsQueryLineStatus request. Problem: If the output buffer specified on any TadsQuery* call is too small for the amount of output being returned, then the daemon processing such a request may end with a runtime exception. Solution: Code modified to properly return rc=TADS_INSUFFICIENT_SPACE for this situation. Name: APAR IC27393 Date: 20 July 2000 Library: 8772 Symptom: Messages in cplog "LListUnblockAccess rc=1" leads to core dump on AIX. Problem: Core dump seen by customer due to internal linked lists within CSEBCP being unlocked when they were not previously locked. This is shown by the message "LListUnblockAccess rc=1" repeatedly appearing in the cplog. Solution: Additional code has been added to not do unlocks of internal linked lists within CSEBCP when the list was not previously locked. Name: APAR IC27322 Date: 12 July 2000 Library: 8745 Symptom: SL1 - Line status on REJECTED event wrongly set to ERROR_TONE. Problem: Customer does MakeCall from analog extension that is onhook. This is correctly rejected by the switch as an error. CPE incorrectly sets the line status to ERROR_TONE in the REJECTED event. Customer attempts to re-do MakeCall using customer application but application has the call in a non-idle state. This is on a SL1 switch. Solution: Additional code has been added to detect this scenario on a SL1 switch and report the line status on the rejected event as IDLE, not ERROR_TONE. Name: APAR IC27092 Date: 30 June 2000 Library: 8689 Symptom: A three party call connection event under certain conditions leads to a core dump. Problem: If a three-party call connected event occurs with no previous events received for this call, CSEBCP has a core dump due to a code problem. Solution: Code modified to not core dump in this situation. Name: APAR IY11401 Date: 16 June 2000 Library: 8649 Symptom: JTAPI Daemon goes down unpredictibly handling a call data event. Problem: On a heavily loaded system where large blocks of call data are attached to calls, the system can run out of memory and cause the JTAPI daemon to core dump/trap in either a malloc or free function call. Solution: Additional code has been added to detect the out of memory condition when handling call data events and discard them. This change only prevents the core dump. More memory must be added to the system or additional equipment used to solve the data loss due to insufficient resources. Name: APAR IC27112 Date: 9 June 2000 Library: 8638 Symptom: Call state changed to ERROR_TONE from connect status after third party call rejected. Problem: A and B are in a call, and C and D are in a call. C requests add-party of B. B attempts to be added to C. The code incorrectly changes the existing party (C's) state from CONNECTED to ERROR_TONE. Solution: Code was modified to maintain CONNECTED state in this scenario. Name: APAR IC27104 Date: 09 June 2000 Library: 8634 Symptom: Calling party's line state is incorrectly changed from HOLDING preventing retrieve Problem: Calling party places a call to a VDN or ACD. Agent is alerted, but agent does not answer. Calling party places the call on hold and then the call is routed from the alerting agent. Depending on the scenario, the calling party's state is placed in ROUTED_TO, DIALING or CONNECTED. The calling party is still HOLDING. Because the calling party's status is incorrect, CP Enterprise refuses to process a retrieve request. Solution: Code modified to maintain HOLDING status for the various incorrect situations. Name: APAR IC26785 Date: 25 May 2000 Library: 8628 Symptom: Add_Party (silent monitor) resulted in changing agent's line state from alerting to connected. Problem: Agent is being alerted. Supervisor does an add_party request. Supervisor is connected to the alerting call. CP Enterprise code reports agent's state as CONNECTED (even though in an alert- ing state). Attempt to do an Answer Call Request is refused in error. Solution: Modify the source code to not force a connected state on the alerting party. Name: APAR IY10698 Date: 18 May 2000 Library: 8231 Symptom: During RICT dial resolution, Escape chars are passed to the switch. Problem: The TADSRICT_DIALRES section of the CSEBPROF.INI allows escape characters such as '\A' to be specified. These should be resolved (e.g. to 'A') during RICT processing but instead are incorrectly passed onto the switch connection. Solution: Modify the source code to parse the Escape character correctly. Name: APAR IY12028 Date: 21 June 2000 Library: 8795 Symptom: csebmon traps when switch invokes RONA feature Problem: In the case of RONA the monitored party is not removed because there is no match between the pMonitoredExt and pAgentAnswered, pAgentOriginated or pAgentDirected. This occurs on RONA because even though the call was routed to a new agent, the current call has not been routed from that agent. The pSegInfo needs to be cleaned up to prevent a trap the next time this agent receives a call. Solution: Modified source code to correct problem. Name: APAR IC27187 Date: 21 June 2000 Library: 8796 Symptom: csebmon traps - bad pSegInfo, problem in pointer cleanup Problem: The reference to the pSegInfo must be deleted before the pAgentDirected pointer is set to NULL. If this is not done a reference to the pSegInfo is maintained in pParties->pMonitoredExt->pSegInfo will not be cleaned up. The next time this party is used it may trap in verifyactivecall. Solution: Modified source code to correct problem. Name: APAR IC27745 Date: 15 August 2000 Library: 8881 Symptom: csebmon traps - bad pSegInfo in mulit-agent calls. Problem: when two or more agents are involved in a call, the pSegInfo pointer in the second agent control block is not being cleaned up properly when the first agent disconnects from the call. Solution: Modified source code to correct problem. Name: APAR IC27808 Date: 25 August 2000 Library: 8893 Symptom: A bug in packet level tracing causes csebmon to trap. Problem: Packet level tracing is being disabled in the source to prevent csebmon from trapping. Solution: Modified source code to correct problem. Name: APAR IC27982 Date: 29 September 2000 Library: 8937 Symptom: csebmon traps when using pSubSeg->pAgentAnswered pointer. Problem: Trap occurs in InitSegement when original agent disconnecnts from a conference. Solution: Modified source code to correct problem. Name: APAR IC28506 Date: 20 October 2000 Library: 8974 Symptom: csebmon trapping on a conference scenario Problem: A pointer was not being checked for null. This would only occur on conferences where more than 3 parties are in the call. Solution: Modified source code to correct problem. Name: APAR IC28507 Date: 20 October 2000 Library: 8975 Symptom: Call Segment duration time 0 Problem: Call segment duration was not being set correctly causing the segment duration to be recorded as 0. Solution: Modified source code to correct problem. Name: APAR IC28508 Date: 20 October 2000 Library: 8976 Symptom: Queue and Delay times not being recored Problem: A call flow that was not being handled was recording queue and delay times as outtime. Solution: Modified source code to correct problem. Name: APAR IC28509 Date: 20 October 2000 Library: 8977 Symptom: Hold time not calculated for transfer off switch Problem: When a call is transferred off switch and there are no monitored parties remaining in the call the hold time was not being calculated. Solution: Modified source code to correct problem. Name: APAR IC28510 Date: 20 October 2000 Library: 8978 Symptom: Disposition not set correctly on calls abandon in queue Problem: Incorrect disposition on calls that were transferred to an ACD queue and then abandon. Solution: Modified source code to correct problem. Name: APAR IC28511 Date: 20 October 2000 Library: 8979 Symptom: Other time not getting set on reject event Problem: Between setup event and reject event no time was being recorded. This time should have been recorded as other time. Solution: Modified source code to correct problem. Name: APAR IC28512 Date: 20 October 2000 Library: 8980 Symptom: Call segments ending early on silent monitor calls Problem: When a call is being silent monitored and the silent monitor drops off this was causing the segment to end. The segment should still be active or marked as holding at this time. Solution: Modified source code to correct problem. Name: APAR IC28513 Date: 20 October 2000 Library: 8981 Symptom: Incoming calls recorded as outgoing calls Problem: On transfer forward to VDN calltypes were being classified as outgoing=12 when they should have been incoming=11. Solution: Modified source code to correct problem. Name: APAR IC28514 Date: 20 October 2000 Library: 8982 Symptom: AgentID missing on SKBR calls Problem: In some cases of SKBR calls the AgentID was not being updated in the Agent control block. This left the AgentID field blank when it should have contained a valid AgentID. Solution: Modified source code to correct problem. Name: APAR IC28608 Date: 26 October 2000 Library: 8995 Symptom: Group number missing on ACD agents Problem: In some cases where the group number was available it was not set. Name: APAR IC28839 Date: 15 Nov 2000 Library: 9021 Symptom: When installing an Enterprise product the following error occurs; "Could not add dll path to autoexec.bat". If this error was ignored on the installation then there will be an incomplete install of the product. Now when service is applied to the product the following error will be displayed; "Not Enough disk space on target drive while attempting to copy files. To continue, first free disk space on the target drive and then click OK." Whether OK or Cancel is chosen the program will result in an endless loop. One must use Task Manager to end the Callpath Service application. Problem: The problem is that some Windows 2000 machines have a hidden AUTOEXEC.BAT file which prevents install from updating the path. This results in a corrupted registry entry. This also causes the service executables to fail which gives the "out of disk space" error above. Solution: The solution is to turn off the hidden attribute from the AUTOEXEC.BAT file, uninstall, and then reinstall. The following steps will assist in the process. 1) Stop all components 2) Turn off the hidden attribute on the AUTOEXEC.BAT file. This can be done by opening a command prompt and from the root directory, usually c:\, type "attrib -H AUTOEXEC.BAT". 3) Copy all of the .INI and/or .DEF files from the conf directory to a temporaray directory. 4) Uninstall the product. 5) Reinstall the product. This time there should be no error messages displayed from the install program. 6) Copy the .INI and/or .DEF file from the temporary directory back to conf. Files contained in this Service Package: ---------------------------------------- csebclnt.txt csebserv.txt bin\csebclnt.exe bin\csebcp.exe bin\csebdbgw.exe bin\csebmon.exe bin\csebjtpi.exe bin\csebprof.exe bin\csebserv.exe bin\csebxmsg.exe conf\cseblims.c01 conf\cseblims.c02 conf\cseblims.cfg dll\csacrcrt.dll dll\csebapi.dll dll\csebbase.dll dll\csebdmon.dll dll\csebintf.dll dll\cseblib.dll dll\csebmwin.dll dll\csebnet.dll dll\csebdres.dll dll\csebutil.dll dll\libcmnr.dll dll\libcpn04.dll dll\vacdapi.dll bin\cfgcfg.jar bin\cfgframe.jar cpcfg.txt