Product: Corepoint Telephony Server
       Version: 6.2.0
         Level: E2065
      Platform: WindowsNT
          Date: 24 July 2001
  Service File: ecswnt.exe
          Size: 2558523  (2.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 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=<value> <username>". 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:
  ----------------------------------------
    setup.bmp
    setup16.bmp
    csebserv.iss
    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