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