Product: Corepoint Telephony Server Version: 6.2.0 Level: E2065 Platform: AIX Date: 24 July 2001 Service File: ecsaix.tar Fileset: csebserv.obj Size: 5120000 (4.9Mb) Checksum: 475663545 Installation Instructions: -------------------------- This Service File is a tar of an installp update fileset. It includes both the fileset, csebserv.obj, and its related .toc file. You must have root authority to install this fileset. - Download ecsaix.tar into a directory. - Extract the fileset using the command "tar -xvf ecsaix.tar". - Start "smit install_update" (for AIX < 4.2 use install_selectable). - Select "Install/Update From All Available Software". - Enter the directory name to which the fileset was extracted. - Enter the fileset name, csebserv.obj, into the field "SOFTWARE to install". Service files are installed with root ownership and root access permissions. If you want users WITHOUT root authority to be able to start or access the Corepoint Telephony Server product files, the following changes are required: - Change the group with the chgrp command for all of the directories and files within the installation path. For example, to permit the Admin group, issue: "chgrp -R Admin /usr/lpp/cseb" - Change the file permissions with the chmod command. For example, "chmod -R g+x+r /usr/lpp/cseb" Fixes contained in this Service Package: ---------------------------------------- Name: APAR IC31047 Date: 13 July 2001 Library: 9548 Symptom: After a network outage between a Callpath Enterprise client and a Callpath Enterprise server is corrected, an application may not immediately be able to re-establish all of its event monitors. Events that can only be monitored by a single application in the system may still be incorrectly marked as being held by an application. Problem: Once the system has recovered from a network outage, a Callpath Enterprise Server may not be aware that a client has gone away or that a client has removed event monitors during the network outage. APAR IC29587 partially addressed this problem by removing event monitors and connections once the server or client could not deliver an event due to a broken connection. But, if there's no events to deliver then this cleanup is not triggered. Solution: If a new TCP socket connection is received, but there's already a connection established with the same host machine then send a heartbeat across the existing connection to verify that it's still an active connection. If the connection is no longer valid, clean up all resources associated with it. Since this is a change in data flow between CEO components, for this fix to be activated the environment variable "TADS_CHECK_CON" must be set to "ON" prior to starting csebserv. Name: APAR IC31019 Date: 12 July 2001 Library: 9543 Symptom: If an agent logs on to an ACD that's not configured in csebprof.ini, then once this agent logs off he is not allowed to log back on. Problem: When an agent is associated with an ACD that's not configured in CEO's JTAPI configuration data, then the JTAPI daemon does not recognize the ACD as valid. This results in incomplete cleanup when the agent logs off. The JTAPI daemon after this point will not allow the agent to log back on. Solution: If an ACD unknown to the JTAPI daemon is associated with an agent, then the daemon will create an entry for the dynamic ACD address in its information area. Name: APAR IC30962 Date: 29 Jun 2001 Library: 9510 Symptom: If you're running on a Nortel SL1 switch and you make a call to a busy phone, you cannot disconnect immediately and it takes up to 16 seconds for the switch to issue the disconnect. If running JTAPI or CallPath Phone, the disconnect occurs automatically "under the covers" after the call to the busy phone and the user cannot issue another call request for up to 16 seconds. Problem: csebcp deletes an internal structure that it shouldn't in this scenario. Solution: Modify csebcp to not delete the internal structure and accept disconnect properly in this scenario. Name: APAR IC30780 Date: 27 Jun 2001 Library: 9479 Symptom: If csebcp receives a "disconnected" event for a particular party while csebcp is still processing a TadsRequestExtend from that party to another party, under certain conditions, 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 IC30779 Date: 27 Jun 2001 Library: 9472 Symptom: If csebcp.ini is set up so that the "Servers" field under [INITIALIZATION] is 16 digits (7600@abcdefghijk), csebcp will not connect to CallPath Server, and error message "STLIPD failed! rc = 5" will appear repeatedly in the cplog. (A 16-digit "Servers" field typically happens if the TCP/IP hostname for the CallPath Enterprise Server is 11 digits, for example, abcdefghijk.) Problem: csebcp does not handle the "Servers" field correctly if it is 16 digits. Solution: Modify csebcp to handle this field correctly when it is 16 digits, allowing csebcp to successfully connect to CallPath Server in this scenario. Name: APAR IC30778 Date: 27 Jun 2001 Library: 9469 Symptom: Occasionally, the error message "LList looping error in LListAddItem" can be seen in logs, such as cplog/cperr or ilberr. No other errors occur other than these messages appearing in the log(s). Problem: csebcp believes there is a problem in its internal list handling when no such problem exists. Solution: Modify csebcp to avoid printing this error incorrectly in this scenario. 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 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 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 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 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 IC26956 Symptom: Unmonitored held party not part of original connected event was not published in the HELD event. Problem: If a call was established by a single party connected event (and the called party was never published) upon a successful extend CallPath would publish the held party as the party that was called in the original call. CP Interface Daemon was not publishing the Held party. Solution: Update the Call State model to capture and report the held party. Name: PMR 07292 Symptom: csebcp traps with access violation under heavy call volume. Problem: csebcp traps during race condition between a TadsRequestExtend request and a abandoned event (CALL_DISCONNECTED) for the same resource. Solution: Modify the source code to correct this condition. Customer must apply this service to correct this condition. Name: APAR IC26750 Symptom: CallReporter GUI shows server port status as down. In csebmon.trc there are 2 error messages: Error obtaining configuration key Enabled, rc = 239 Error with input parameters, rc = 239 Problem: Timeout occurs when requesting configuration data. Solution: Modify the code to re-request configuration data. Name: APAR IC26709 Symptom: Under very heavy load (especially repeated TadsRequestReturnControl calls) APIs may timeout. Problem: For many APIs CSEBCP needs to check the state of existing calls. This was being done in a less than optimal way, potentially causing slower overall throughput. Solution: Modify the code to handle API state checks more efficiently. Name: PMR 48786 Symptom: CSEBCP traps Problem: When a TadsRequestDisconnect is used at the same instant the external caller hangs up, one threads tries to access memory already released by another, so a trap occurs. Solution: Update code to avoid this problem. Name: APAR IC26684 Symptom: The ulQueueTime field of the TADS_ACD_STATUS resulting from a call to TadsQueryACDStatus had an invalid value. Problem: A fix in build E1738 (unrelated to queue statistics) had a typo that invalidated the ulQueueTime calculation. Solution: Correct the typo Name: Defect 8393 Symptom: May cause timing problems at jtapi client when issuing request to jtapi daemon. Problem: The JTAPI daemon checks for outstanding request on the CALLDATA event for the monitored extension which results in positive responses for unrelated requests. Solution: Modify the code to handle this condition. JTAPI daemon will not try to check for outstanding requests on receiving the CALLDATA event. Name: APAR IC26464 Symptom: Slow API processing and delayed event handling if TadsDisconnectFromServer is called at a high rate ( > 1/sec) Problem: A TadsDisconnectFromServer causes cleanup of internal resources. Very little else can run while this is going on. The application is also blocked while waiting to get access to those resources ( becomes significant is many applications are calling TadsDisconnectFromServer all at the same time). Incorrect logic also meant that under some circumstances, not all the necessary resources were freed. Solution: Update the TadsDisconnectFromServer logic to avoid leak, and move processing to background thread. Name: APAR IC26644 Symptom: An application may receive a TADS_CONFERENCED_EVENT or TADS_ROUTED_TRIGGER_EVENT even when not monitoring for it. Problem: If an application was monitoring a device for TADS_CONNECTED_EVENT (but not TADS_CONFERENCED_EVENT), and another application happened to be monitoring the same device for TADS_CONFERENCED_EVENT, the first application would receive any TADS_CONFERENCED_EVENTs generated for that party as well as any TADS_CONNECTED_EVENTs generated. The second application was unaffected. If an application monitored a device for TADS_ROUTED_TRIGGER_EVENT and then another application monitored the same device for some other events, the first application would not receive any TADS_ROUTED_TRIGGER_EVENTs generated for that device. The second application would receive the TADS_ROUTED_TRIGGER_EVENTs, as well as the events it had monitored for. Solution: Update the event generation logic to handle these cases correctly. Name: APAR IY08901 Symptom: Scenario: A calls B(b1) and connects, X calls B(b2) and B remains alerting, b1 extends and transfers to C. The Alerting event for the B-C call carried the original call block for the X-B call instead of the A-B call resulting in the incorrect inference of relating the B-C leg of the call with the X-B call. Problem: The problem is that when the Telephony Interface Deamon processes the CallPath Alerting event for the B-C call, it tries to make an inference association with an existing call of B. The inference is done by searching the CIDList based on extension B because all the CIDs carried in the event are new. Since there are two calls with extension B in the cidList, the Alerting event processing picks the first call found in the CIDList. Solution: The Fix has two phases: First, if the G3 SD code will put the extending_CID in the Held event for the A-B call, then the Telephony Interface deamon will be able to explicitly retrieve the appropriate call (A-B). The G3 SD can put the extended_to field in the Held event only on extends that are issued through the API. To handle the manual case, the Telephony Interface daemon has to change to pick a party in the Held state. However, this only "closes the opening of the window" but does not shut it, since its possible that there can be two calls on hold. As a result, the Telephony Interface daemon will just pick the first Held party. That's the best we can do since the switch protocol and/or CallPath does not provide a tag to correlate legs of the same call. Name: PMR 77743 Symptom: If a call appears inactive for more than 2 hours, it is cleaned up automatically. If that call happened to be at a queue, the Estimated Wait Time for that queue continued to rise even after the call had been cleaned up. Problem: Cleanup code was not updating the Queue's wait time data. Solution: Update code to avoid this problem. Name: PMR 48742 Symptom: If a supervisor silent monitors an idle agent, but is itself called before the agent connects to a call, the events have incorrect data. Problem: If the supervisor is waiting for a silent monitor on an agent to mature (i.e. the agent to connect to a customer call) it is still possible for someone else to call the supervisor. The supervisor has the option of ignoring their alerting phone and instead be connected into the agents call when it connects. In this case, the customer and agent were incorrectly added to the supervisors alerting call rather than having a separate call containing the customer, agent, and supervisors silent monitor. Solution: Update code to avoid this problem. Name: PMR 01927 Symptom: AgentStatus events were not flowing when Enterprise connected to a on a NONEASE Lucent PBX. Problem: On the Lucent G3, the switch may contain the EASE feature. If it does, only FeatureInvoked monitors are allowed on the hunt group. This will translate into agent login and logout events. If the switch doesn't have the EASE feature, two behaviors are possible; the traditional behavior was that only call progress events (Call_Routed) were monitorable on the hunt. However, it seems that some NONEASE configurations allows both FeatureInvoked and Call Progress monitoring on the hunt group. Solution: Talk to service before activating this behavior. Name: PMR 08468 Symptom: On the Lucent G3, if a revertive (i.e. predictive) call was made to a forwarded mobile phone, the calling party (VDN) in the rejected event was given a different callid to that of the called party (mobile phone). Problem: Since, in a predictive call, the calling party is added to the call AFTER the called party, the handling of the rejected case assumed the new (calling) party should be in a new leg. Solution: Modify code to assign the calling party to the same call as the called party. Name: PMR 65936 Symptom: For external inbound calls over a non-intelligent trunk (i.e. calling party number = "") that were eventually manually extended to an external party, the external connection of the extended leg (but not the internal half of that extended leg), was given a new callid. Problem: Code incorrectly deduced the original inbound external caller ( "" ) was the same party as the external extended-to party ( "" ). It then assumed this party was itself extending so allocated a new callid. Solution: Modify code to avoid assigning a new callid in this case. Name: Defect 8278 Symptom: On calls which have parties which are in TADS_STATE_CONNECTED_RCV_ONLY state (aka silent monitor), HELD events may be processed incorrectly, resulting in one party incorrectly changing from TADS_STATE_CONNECTED to TADS_STATE_HELD state. This party should remain in the TADS_STATE_CONNECTED state. Problem: HELD event processing did not take into account that there could be parties connected in the call in receive only mode. These parties do have a one-way voice path established which continues to be functional. Solution: Modify code to reflect correct states for all parties on HELD events. Name: Defect 8267 Date: 09 Feb 2000 Symptom: CallStats events were being generated when only external parties were in the call. Problem: Call Reporter relies on the Call Stats Event generated by the Interface Deamon. The Call Stats event tracks the call as long as there is a monitorable resource in the call. However, the Call Stats event was being generated after all monitored parties had left the call. For instance, an external party calls an agent, the agent performs a blind transfer to another external party. Even though the agent gets out of the call, a Call Stats event would be generated to indicate when the two external parties left the call. This additional event would confuse Call Reporter into generating an additional call record in its database since it closed the previous record based on the Transferred event. Solution: Modify the code to only send Call Stats if at least one of the parties carried in the event is a party known by the Interface Deamon through configuration(monitorable party). Name: Defect 8213 Date: 17 Jan 2000 Symptom: Reconfiguration of JTAPI users performed by the CPE configurator require restarting the JTAPI Daemon to take effect. Problem: The JTAPI Daemon needs to be responsive to configuration changes without having to bring down a call center in production. Workaround: None. Solution: The JTAPI Daemon was updated to respond to a TadsRereadINI event that is sent when a reconfiguration occurs. The daemon detects the JTAPI user address and/or ACD address changes and will send a provider SHUTDOWN event and close the provider session only to the affected users. Configuration changes made to a JTAPI user exclusively for toolbars, speed dial buttons, or passwords have no effect on a session. This change introduces a new type of JTAPI user called a dynamic user. A dynamic user has no preconfigured addresses or ACD addresses. Users with addresses of either type are called static users. To handle dynamic users, a new JTAPI java client has been released with a modified JtapiPeer.getProvider() request. The new JtapiPeer.getProvider() request allows two additional tags to specify addresses and/or ACD addresses to use for this session. The format is ... This new functionality is only available for dynamic JTAPI users. Static JTAPI users that attempt to use this request will be denied for security reasons. Existing JTAPI applications (see note 1) will continue to function as before without repackaging and will receive a SHUTDOWN event if reconfigured. Note 1: The existing release of CPPhone (as of the end of 1999) will not correctly respond to reconfiguration changes. It will receive a SHUTDOWN event, but the deleted addresses will still exist on the screen and the new ones will not appear. CPPhone must be shutdown and restarted in order to start operating with the new configuration changes. A new release of CPPhone is available in parallel with the new JTAPI Daemon that will correctly handle address reconfigurations. String myArgs = new String( "7600@cp01;login=george;passwd=gwc552;" + "addresses=1111,2222;acdaddresses=3333,4444;" ); Provider myProvider = getProvider(myArgs); Name: Defect 8236 Symptom: Retrieve fails for a held call where the far end party is on the network. Problem: JTAPI daemon does not create a terminal connection for the party whose connection is either in the NETWORK_REACHED or the NETWORK_REACHED_ALERTING state. Upon issuing the Retrieve (Unhold) request, the JTAPI daemon receives CONNECTED event (reconnect reason) for the local party. JTAPI daemon tries to update the terminal connection state of the far end party which returns an error since there is no terminal connection for it. As a result the CONNECTED event is discarded by the JTAPI daemon and no call event is sent to the JTAPI client which never releases the Unhold request from the application. Solution: Modify the code to handle this condition. JTAPI daemon will not try to update the state of the terminalConnection for the far end, if the party Connection is either in the NETWORK_REACHED or the NETWORK_REACHED_ALERTING states. Name: PMR 48742 Symptom: Lucent G3: Call Reporter not informed when a call is disconnected on a specific rejected flow. Problem: On a CallRejected produced when the error_in_called party and calling party not monitored, call cleaned before receiving Disconnected. Although Lucent supports call tracking, CPDMON wasn't waiting for the Disconnected to be sent by Corepoint Telephony. Solution: If the switch that CPDMON is connected to supports call tracking the Call_Rejected processing will wait for the Disconnected to be sent by the switch for the calling party. Here's the scenario: Party A is not monitored. A calls B which is monitored and busy. CPDMON receives a Call_Rejected with error_in_called_party, reason = busy. Previously to this fix, CPDMON said that if the calling party wasn't monitore we wouldn't expect any more events so clean up the call. Now, CPDMON will not cleanup the call if the switch supports call tracking and if the switch supports only resource tracking, CPDMON will continue to cleanup the call but will also issue a Disconnect event to the application. Name: Defect 8188 Symptom: Intermittent csebcp Trap when a single party Alert message is received. Problem: On some switches for particualr call flows, a single party Alert message can cause the Corepoint Telephony Daemon to trap. Solution: Modify code to gracefully handle this condition. Name: Defect 8218 Date: 14 Jan 2000 Symptom: The OriginalCallInfo on the receiving node is blank for calls processed by NACD. Problem: This only occurs if the first event for the call shows the call entering the NACD. Workaround: None Solution: Logic updated to ensure the OriginalCallInfo is always updated for NACD calls. Name: Defect 8206 Date: 10 Jan 2000 Symptom: Cplog has large number of messages saying "Clearing NetworkCallID= " Problem: Variable used to search list was cleared inside search loop. Workaround: None Solution: Logic update to avoid clearing search argument. Name: Defect 8203 Date: 10 Jan 2000 Symptom: Nortel SL/1 Network ACD functions will give unpredictable results. Problem: Nortel SL/1 Network ACD functions not working correctly. Workaround: None Solution: Make necessary changes to CSEBLIMS.C01 Name: Defect 8103 Date: 22 Dec 1999 Symptom: Under very heavy load, NACD and RICT operations cause Csebcp crash. Agents not getting RICT/NACD screen pops. Problem: Apparent logic errors and memory depletion. Workaround: None Solution: Improve efficiency and robustness of memory utilization, RICT, NACD and tracing. Cleanup memory when NACD call handled on the same node the call entered the NACD. Handle unusual event flows from stressed switch. Remove potential deadlock if an application calls TADSSetCallData at the same moment a RICT call arrives. Remove potential error when deleting CIDs Name: PMR 70266 Date: 15 Dec 1999 Library: Defect 8160 Symptom: When a call is made into a queue and subsequently is routed out of the queue, the time_in_queue field in the CallInfoBlock is not being completed correctly on the CallRouted ROUTED_FROM event. Problem: Order of method calls were incorrect. The event to be generated was created before the Time_In_Queue field was calculated. Workaround: None Solution: Calculate the Time_In_Queue before created the event to generated. Name: Defect 8149 Symptom: Messages destined for applications can be larger than CPE currently supports. A new return code indicates that condition. Problem: Applications need to be informed if the message that some daemon wanted to send grew bigger than CPE supports. This return code was already added in this release for the Profile Daemon. But needed to add support for TadsQueryErrorText to recognize it. Workaround: None Solution: Add new return code. Name: PMR 74903 Library: Defect 8129 Symptom: JTAPI Daemon did not come up because JTAPI Daemon was not informed that Profile Daemon had come up. CPE Server did not inform JTAPI Daemon. Problem: CPE Server code can piggy back the daemon UP status report with another event. If daemon UP status report and other event occur close enough together, a small timing hole allows the UP status report to be lost. Workaround: Don't bring up all CPE components (server, daemons) all at once. Reduces timing hole. Solution: Expand the scope of a semaphore that was intended to prevent this problem. Name: PMR 08032 Symptom: On certain type of trunks(found in Japan), A predictive MakeCall made from a VDN to an external number will result in a trap if the first event after the MakeCall is a single party connect containing only the external party as the connecting party. Solution: Perform some extra checking for the unforeseen case. Name: PMR 71603 Symptom: On large csebprof.ini files, sometimes the Corepoint Telephony Daemon would crash when the JTAPI Daemon makes certain request. Solution: This has been fixed. Name: Defect 8094 Status: This service is required for the Corepoint Telephony Java Configurator service S6B18 or later. Name: Defect 8122 Symptom: Message "[JTAPI], JTAPIUsers - is too large. Data entries are limited to 64000 characters" occurs when running the java configurator. Detail: This requires the latest Corepoint Telephony configuration daemon and the latest Corepoint Telephony configuration tool. Check the csebprof.ini file to determine if the JTAPIUsers value is indeed larger than 64k. There are 2 distinct problems. Scenerio1: JTAPIUsers value >= 64k (this can happen with 150 to 300 jtapi users). Cause1: CEO cannot send messages with data segments larger than 64k bytes. Solution1: - Either the offending section must be reducted in size, or - The latest corepoint telephony configuration daemon and the corepoint telephony java configuration tool must be down loaded. - The configuration daemon must be placed on the server machine and the configuration tool must be placed on all client machines which will used to access configuration. - Shut down the corepoint telephony configuration daemon. - The csebprof.ini file must be converted to a new format by placing the UserUpdate.jar in their classpath and running: 'java UserUpdate old.ini new.ini' backing up their old csebprof.ini and replacing it with the converted csebprof.ini Scenerio2: JTAPIUsers value < 64k (or any other key value). Cause2: There is a mismatch between the versions of Corepoint Telephony Configuration daemon and the Corepoint Telephony Configuration Tool. Solution2: - Download the latest Corepoint Telephony Server (which includes the configuration daemon) from the service site. - Download the latest Corepoint Telephony Configuration Tool. - Distribute the configuration tool to all client workstations requiring it. Note that no csebprof.ini conversion is necessary at this point. Name: PMR 27619 Date: 15 Dec 1999 Library: Defect 8155 Symptom: Parties A and B are in a call. Supervisor, S, silently monitors agent B. Party A transfers the call to party D. When party D connects, party S reported the incorrect state of CONNECTED. Problem: Transition from state CONNECTED_RCV_ONLY to state CONNECTED was made without validation. Workaround: None Solution: Put in code check to prevent transition from CONNECTED_RCV_ONLY to CONNECTED. Name: Defect 8107 Date: 17 Nov 1999 Symptom: A make call that generates a two party connected event does not publish the Program Data. Problem: On the G3 swith, it is possible to get an event flow that skips the the alerting event on the original make call. The final connected event which contains two parties is not correctly processed causing an omision of the Call Data (Program Data) normally seen in a one party connected. Workaround: None Solution: Modify the code to handle this condition. Name: PMR 70305 Date: 09 Nov 1999 Symptom: If an application is monitoring only an internal DN that is the target of a Conference operation, no CONFERENCED event will be received. Problem: The Corepoint Telephony Daemon was not monotring for secondary parties for CONFERENCED events on the SL/1. also, a logic flaw prevented this event from being processed. Workaround: None Solution: Modify cseblims.cfg file and correct logic flaw in Corepoint Telephony Daemon code. Name: Defect 7707 Symptom: Insufficient memory allocation for the GetProvider request caused overwriting of the stack Detail: GetProvider request from a client monitoring an ACD address (with more than 20 active calls) caused overwriting of the stack, since memory was allocated for only 20 calls, which is the maximum number of calls a non ACD address can handle. However the same memory is used to return information for calls in an ACD. Need to allocate sufficient memory to handle max calls in an ACD. Name: Defect 7956 Symptom: ApplicationData is sent across the network as single byte characters. Needs to support double byte. Detail: If a String containing double byte characters is passed on the Call.setApplicationData() method, the data will not be correct in another Jtapi client, or in a Corepoint Telephony client. To fix this, the data associated with the call will be incoded and decoded using the UTF-8 standard. If a Jtapi application data wants to share double byte characters with a Corepoint Telephony client, the Corepoint Telephony client must encode and decode call data using the UTF-8 standard. This approach will not break existing applications that use single byte ASCII character strings. Name: Defect 6526 Symptom: Support SKBR agents with switches which do not require ACD and/or agentID. Detail: Certain switches do not support ACD and/or agentID for agent state change requests. This is reflected to the JTAPI daemon via the cseblims.cfg. As a result of this switch limitation JTAPI daemon removes the ACD and/or the agentID before issuing the corresponding agent state change request to CEO. However if the agent is a SKBR/VACD agent they might need the ACD and/or agentID for agent state change requests. The approach is to check if either SKBR or VACD is running then JTAPI daemon will not strip the agentID and/or ACD when issuing the corresponding agent state change request to CEO. Name: PMR 46144 Library: 8099 Symptom: System is slow and connection between server and daemon may be lost. Problem: If a daemon is sending lots of events or replying to the server with large amounts of reply data, the server's receive thread does not issue the TCP receive requests quick enough. This results in many occurrences of the "would block" return code (10035) when the daemon attempts TCP send requests. Workaround: Register for fewer events and avoid using requests to poll. Solution: Code changed to increase the priority of the receive thread. Name: Defect 8071 Symptom: Corepoint Telephony Reporter will lose track of some calls. Problem: New CallID's generated when Corepoint Telephony Daemon receives a Routed event where the Routed_To and Routed_From parties are the same. Workaround: None Solution: Code updated to prevent this from occurring. Name: Defect 8063 Symptom: CPU goes to 100% and no more events are received from the Telephony server. Problem: When sending an event to multiple applications, the telephony interface deamon omitted to clear some data. This caused the code to get into a loop condition that never terminated. Workaround: None Solution: Code updated to clear the pointer and prevent the loop condition occuring. Name: PMR 54334 Library: 8049 Symptom: A broken TCP connection between a Corepoint Telephony server and daemon results in a hung daemon. Problem: A send error caused the TCP connection between a server and the SKBR daemon to be broken. Once broken, this connection was not automatically re-established resulting in a hung daemon. The daemon had to be restarted. A broken server to daemon connection should be automatically re-established. Workaround: Daemon must be stopped and restarted. Solution: Code updates were made to re-establish the Corepoint Telephony server to daemon connection once a connection is found to be broken. Name: PMR 52481 Library: 8013 Symptom: Some TADS_MAXLEN... constants are undefined in the Rexx environment. Problem: The following constants are undefined: TADS_MAXLEN_APPLSTRING TADS_MAXLEN_EVENTDATA TADS_MAXLEN_CLIENT_NAME TADS_MAXLEN_ERRORTEXT TADS_MAXLEN_PARTY_ID TADS_MAXLEN_PATHNAME Workaround: Assign the appropriate values in the Rexx script. Solution: Updated CSEBREXX.DLL to expose the constants. Name: Defect 8048 Symptom: TrxGetEvent() not returning a TADS_CALL_ACTION_PROVIDED event correctly Problem: When parsing an event received from the Corepoint Telephony server, CSEBREXX.DLL doesn't check for the event being a TADS_CALL_ACTION_PROVIDED. Workaround: None Solution: Added logic to CSEBREXX.DLL to handle the TADS_CALL_ACTION_PROVIDED event. Name: PMR 51649 Library: 8044 Symptom: Under some circumstances a call previously transferred via the RICT Private/Redirect method on a Nortel SL/1 (MeridianLink 4 or lower) can cause a subsequent RICT transfer to lose its CallData or have CallData from a third call incorrectly attached. Problem: If an agent decides not to handle an ACD call, they can hit the MakeSetBusy or NotReady keys to "bounce" the call back into the ACD. If this is done on MeridianLink 4, Disconnected events are received and any data associated with the call is removed (this part is a Nortel switch issue). When the bounced call subsequently appears at an agent it can potentially interfere with any call that happens to be using the same RICT transfer pool resource (CDN) as was originally used by the bounced call. This can result in the new call not getting its CallData, or getting the CallData from another in-progress RICT transfer. This problem may occur if using a higher version of Nortel MeridianLink but with a Base Telephony Server configured for MeridianLink 4. Workaround: Avoid using the MakeSetBusy or NotReady keys to bounce calls back to the ACD. Solution: Code updates to ensure that a bridge resource is freed ONLY for the same CallID that caused the redirection in the first place. Name: Defect 8050 Symptom: Trap occurs when a multiple legged call ends. Problem: Defect introduced by defect 8027 results in a freeing of a CallBlock list after the CallBlock pointer was NULLED out. Note that the trap occurs only in OS/2 and WinNT OS. Workaround: None Solution: Change code to free the CallBlock list prior to deleting the CallBlock. Name: Defect 8027 Symptom: Warning that there are too many parties in Conference Call. Problem: Multiple too many parties in a Conference call followed by a core (trap). Net is that the connection ids in the CallBlock were not being deleted. Workaround: None Solution: Change code to delete connection ids against a CallBlock even if the same connection id was not found on a global list of connection ids do to an earlier deletion. Name: Defect 7863 Symptom: Blind Transfer would not execute Problem: External call in place. Agent executes ablind transfer call. Extend works, but transfer doesn't complete. Workaround: None Solution: Code defect found that prevented the code from traversing the blind transfer path. Name: PMR 21873 Library: 7957 Symptom: A lot of 0-byte files in /tmp (AIX). If allowed to continue, system could eventually run out of inodes. Problem: Enterprise API library creates named pipe files in /tmp to represent application queues (synchronous and asynchronous). In the past, synchronous queues were created for each API request and deleted as each request was completed (or timed out). The overhead of creating and deleting all of these files could get expensive in AIX since journalling (JFS) was logging all of this activity to preserve the file system integrity. A change was made so that less files were created and they were not destroyed as frequently, which reduced the IOWAIT (since less journalling). But in some environments, this change led to too many of these named pipe files in /tmp. Partly because some applications, instead of just connecting to a Server and issuing requests, take as input the request to connect to a server and issue a request and disconnect. So this application does many connect to server requests in its lifetime, which means a number of named pipe files could accrue. And they weren't going away until the application terminated. Further, this customer's application wasn't terminating normally. So the apilib destructor never had a chance to run and so these named pipe files weren't getting cleaned up. Workaround: None Solution: The named pipe files associated with a particular ConnectToServer instance are now cleaned up as part of DisconnectFromServer, in addition to the logic to remove all named pipe files for the application at application termination. The benefits of this are that there is less reliance on an application terminating normally for these named pipe files to be cleaned up. And, in the case of applications that do many ConnectToServer and DisconnectFromServer requests, there is less accrual of named pipe files during the application's lifetime. Name: Defect 7959 Symptom: The last 2 lines for the [LGIC] switch stanza are missing. Problem: TADSRULES 70-89 have no defined value. This may cause unexpected Corepoint telephony server behaviour when connected to a LGIC switch. Workaround: Add value '1' rule 70, value '0' for rules 71-89. Solution: Entries for rules 70-89 added to CSEBLIMS.CFG and CSEBLIMS.C02 Name: Defect 7949 Symptom: Added support for Trunk Extensions for CSTA switches. Problem: Report Trunk Extensions as VRU Party types in Corepoint Telephony events. This will allow Corepoint Telephony Reporter to recognize and track these calls. Workaround: None Solution: Additional functionality added to Corepoint Telephony Daemon. Trunk Extensions must be configured appropriately to enable this mechanism. Name: Defect 7940 Date: 04 August 1999 Symptom: csebcp.exe will trap due to referencing from NULL pointers. Problem: In certain switches, invalid flows will be generated that ultimately cause cspecp to trap. Workaround: This is a working around to keep csebcp up and running even though the switch is generating incorrect events. Solution: Check for NULL pointers before referenceing. Name: Defect 7745 Date: 11 June 1999 Symptom: Semaphore timeouts in CP Daemon log files. APIs take a long time. Problem: A logic flaw in the Event Processing Thread results in a perpetual loop causing a CPU maximum utilization and a semaphore timeout in the other threads that are processing client API requests. Workaround: None. Solution: Correct logic in Corepoint Telephony Interface Daemon component. Name: Defect 7938 Symptom: DBTADS_PARTY_INFO structure's usStatus field, line state for szExtension, is stated to be a member of TADSExtensionTypes enum. This enum is not shipped with product. Problem: DBTADS_PARTY_INFO structure's usStatus field, line state for szExtension, is stated to be a member of TADSExtensionTypes enum. This enum is not shipped with product, therefore, the enum values are not available. Workaround: The enum values that may be used are found in CSEBDEF.H in enum TADSPartyStates. CSEBDEF.H is shipped with the product. Solution: Documentation will be changed to reflect the correct enum to be used. Name: Defect 7919 Date: 09 July 1999 Symptom: Semaphore timeouts in CP Daemon log files. TadsRequestConference APIs take a long time. Problem: A logic flaw in the TadsRequestConference API results in a semaphore timeout condition. Workaround: None Solution: Correct logic in Corepoint Telephony Interface Daemon component. Name: Defect 7818 Date: 9 June 1999 Symptom: A RICT/IS-ICT call does not have any Call Data on target switch. Problem: In a RICT or IS-ICT operation using a PRIVATE method (PRIVATE/Standard or PRIVATE/Redirect), the original CallID and Call Information is sucessfully passed on to the remote telephony server, but the Call Data of the original call is not. Workaround: Use the ISDN or ANI method (if possible) for RICT/IS-ICT operations. Solution: Correct logic in Corepoint Telephony Daemon component. Name: Defect 7689 Date: 20 May 1999 Symptom: Blind Conference may fail port on Lucent G3 switch. Problem: The logic to locate the active call in the TadsRequestConference API is incorrect. In some scenarios, the active call will not be found, and the API will fail. Workaround: None Solution: Correct logic in Corepoint Telephony Daemon component. Name: Defect 7622 Date: 06 May 1999 Misconfigured NACD may cause trap. Symptom: Trap may occur is NACD support is incorrectly modified in csebprof.ini file. Problem: If NACD support is manually turned off in csebprof.ini file for a switch that is the target of an NACD operation, a trap may occur. In order for this situation to arise, the Corepoint Telephony Server that is the source of the NACD operation must have NACD support enabled, and the Corepoint Telephony Base switch code must also have NACD support enabled. Workaround: Correct configuration file. Solution: Correct logic in Corepoint Telephony Daemon component. Name: PMR 12071 Date: 30 April 1999 Symptom: Intermittently, NACD calls will show old call data. Problem: The RICT dynamic data update feature interferes with the NACD data distribution mechanism, occasionally overwriting new call data with old call data. Workaround: Don't intermix NACD and RICT operations. Solution: Correct logic in Corepoint Telephony Daemon component. Name: Defect 7534 Library: 27 April 1999 Symptom: DMS-100, API request not executed after multiple calls extend to same unmonitored party. Problem: Multiple calls can extend to the same unmonitored party. When the ROUTED/Direct_Route event is received from a DMS-100, CEO mistakenly cleans up any pre-existing calls to this same unmonitored party. Any subsequent API request to one of these cleaned up calls will be rejected by CEO, usually with an "invalid state" type error code, since CEO has wiped out this call. Workaround: None Solution: Correct logic in Corepoint Telephony Daemon when ROUTED event handler. Name: PMR 22402 Date: 13 April 1999 Symptom: Retrieve on held calling party will not work after the called party answers. Problem: CMVC 7488. For the G3 switch, a party can call another party, and while the called party is Alerting, the calling party can put the call on hold. If the called party then answers, the calling party's state is incorrectly changed to CONNECTED. A subsequent TadsRequestRetrieve on the calling party is (incorrectly) rejected because Corepoint Telephony Daemon believes the party is not held. Workaround: None Solution: Correct logic in Corepoint Telephony Daemon when called party connects. Name: APAR IX87425 Date: 16 Feb 1999 Library: 7261 Symptom: Cannot add NACD Queues through Corepoint Telephony Configuration utility. Problem: The validation logic for adding NACD Queues in the Corepoint Telephony Daemon is incorrect. This logic is called by the Corepoint Telephony Configuration Utility prior to "Committing" (i.e. writing) changes to the configuration files. Since the validation fails in this case, no changes will be written. Workaround: NACD Queues can be configured manually. Solution: Correct validation and addition logic for adding NACD Queues in Corepoint Telephony Daemon logic. Name: APAR IC23169 Date: 10 Feb 1999 Symptom: The Corepoint Telephony Interface GUI will show that a RICT connection is available ("UP"), when in fact the initialization has failed no call data can be transferred. Problem: The Corepoint Telephony Daemon does not adequetly check for error conditions when initializing RICT. Workaround: When RICT operations are failing, try to stop/start the Corepoint Telephony Interface. Solution: Improve error checking so that the true state of the RICT connection is displayed. Name: PMR 73356 Date: 8 Feb 1999 Symptom: When connecting with the SL1 Meridian, the calling party and the entire call block gets cleaned up during the processing of a Call_Rejected event independent of the party in error indication. This causes the callID to not be accessible by the application so it cannot issue a Disconnect for the calling party if the calling party is still in the call. Problem: On a Call_Rejected the calling party stays in the call if the error indication indicates that the error is in the called party. Consequently, an application can expect to eventually receive a Disconnected event for the calling party. If the calling party is still in the call, it is possible to disconnect the calling party if the request to disconnect is processed by the switch before the switches internal timer which automatically disconnects the calling party after a Call_Rejected. If the error is in the calling party, a disconnected event will not be generated because the calling party transitions to the IDLE state in that case. Workaround: None Solution: Changed code for SL1 to follow the CSA architecture and only cleanup the calling party and call if there is an error in the calling party. Name: PMR 43550 Date: 20 Jan 1999 Symptom: When printing out the stem variable for the CallStatus structure, the x._CallStatus._OriginalCall._szTrunk and x.i._PartyCallInfo._szCallingPartyNumber fields would be displayed as X._CALLSTATUS._ORIGINALCALL._SZTRUNK and X.I._PARTYCALLINFO._SZCALLINGPARTYNUMBER, respectively. Problem: The fields were not properly extracted from the API and place in the stem variable. Workaround: None Solution: Changed code to properly extract and place fields in stem variable. Name: PMR 09272 Date: 14 Jan 1999 Symptom: Trap occurs if the call in place is deleted by the event handler while the request handler is processing an Extend and RICTResolveNumber function is attempting to get a RICT line. There is only a very small window of time where this situation can occur. Problem: Valid cid entry pointer to the call block is NULLed out by event processing (disconnect event) as the TadsCPRequestExtend is processing and called RICTResolveNumber using a valid cid entry pointer. RICTResolveNumber uses the cid entry pointer's pointer to the CallBlock and when it does, the pointer to the CallBlock is NULL. Use of the NULL pointer is an illegal operation which causes a trap. Workaround: None Solution: Prior to RICTResolveNumber using any pointer, make sure the pointer has not become NULL. Return an INCOMPATIBLE_STATE return code if a working pointer is found. Output diagnostics and avoid continuing the extend request. Name: APAR IX84411 Symptom: If call to Rolm 9006 agent has been abandoned, there is no agent status event and the agent's state cannot be changed to unavailable. Problem: After agent on Rolm 9006 has been alerted, caller abandons prior to connection. The agent status event for the abandon does not change (i.e., the agent remains in an alerting state within Telephony call state model). Agent status corrects when a call is in a connected state for this agent or the agent has been logged out. The solution was to swap parties in the internal call to "SendDisconnectedEvent" procedure. The problem arose because the switch swapped parties and the Telephony Interface Daemon code was partially modified to swap the disconnecting and disconnected parties. The modification did not fix the code that deals with publishing the Agent status event. Name: APAR IC22433 Symptom: Incorrect error message when RESETOUTAGE = -1. Problem: An incorrect error message will be generated when the RESETOUTAGE variable in the TADSCP section of the csebprof.ini file is set to -1 (the default value). Workaround: Ignore error message. Solution: Fix error message. Name: Defect 4814 Symptom: QueryCallInfo program call may cause trap. Problem: On heavily loaded systems, QueryCallInfo may cause a trap due to semaphore locking logic problem. Workaround: None Solution: Reduce granularity of semaphore lock requests, allowing Query functions to complete processing before releasing the semaphore. Name: APAR IX82684 Symptom: Telephony Interface Daemon (csebcp.exe) Traps on CALL_PICKED Event. Problem: In Interface Daemon, if a Call_Picked event is received where the Connecting Party CID already exists, the Interface Daemon will trap. This is usually a secondary effect from a Telephony Switch Dependent code problem. Workaround: Correct event flow from Telephony Base Server. Solution: Correct logic in Interface Daemon Call_Picked Event Handler so that it no longer attempts to use a NULL pointer. Name: APAR IY12028 Date: 21 June 2000 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. Workaround: None Solution: Modified source code to correct problem. Name: APAR IC27187 Date: 21 June 2000 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. Workaround: None Solution: Modified source code to correct problem. Name: APAR IC27745 Date: 15 August 2000 Symptom: csebmon traps - bad pSegInfo in multi-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 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 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 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 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 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 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 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 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 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 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 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 Library: 8995 Symptom: Group number missing on ACD agents Problem: In some cases where the group number was available it was not set. Files contained in this Service Package: ---------------------------------------- cseb/bin/csebserv cseb/bin/csebcp cseb/bin/csebmon cseb/bin/csebprof cseb/bin/csebxmsg cseb/bin/csebjtpi cseb/conf/cseblims.cfg cseb/conf/cseblims.c01 cseb/conf/cseblims.c02 cseb/lib/libvacdapi.a cseb/rc/Csebserv cseb/rc/csebserv.xpm cseb/rc/Csebcp cseb/rc/Csebprof cseb/rc/Csebxmsg cseb/rc/Csebjtpi cseb/text/csebserv.copyright cseb/text/csebserv.txt