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