Product: CallPath Enterprise Server Version: 2.02.01 Package Name: ecsw1978.exe Size: 3146004 (3072Kb) Level: 1978 How to install: download the self extracting file, ecsw1978.exe, to a temporary directory. Run it from any command line and follow the prompts. This will start an InstallShield Wizard to guide you through the installation process. Fixes: APAR IC29486 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. APAR IC29098 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. APAR IC28932 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. APAR IC28805 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. APAR IC28539 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. APAR IC28318 Symptom: Calling party's line sate 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 (or there is no agent on the queue at this time). Calling party places the call on hold and then the call is routed from the alerting agent (or to an agent that appears on the queue, if the queue was empty). 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 or conference request. Solution: Code modified to maintain HOLDING status for the various incorrect situations. APAR IY12500 Symptom: Connections to a CallPath Enterprise server are refused. Problem: A couple of limits are reached once the number of TCP socket connections to a AIX CallPath Enterprise server (CSEBSERV) nears 2000. The first limit reached is the number of open files allowed per AIX process. The default open file limit is 2000. This limit can only be changed in AIX 4.3.1 or later. To change this value for the user that's running CSEBSERV, use the command "chuser nofiles= ". The next limit reached is the number of TCP socket connections allowed by CSEBSERV. This limit is being increased by this APAR. Solution: Increased the maximum number of allowed TCP socket connections from 2048 to 8192 for AIX (from 2048 to 4096 for Windows NT). APAR IC27407 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. APAR IC27162 Symptom: Unmonitored held party, not part of original SETUP event, is not put in call state model. Trap when CONNECTED event processed. Problem: If a call was established by a setup event and then a HELD event occurs, held party is ignored. Subsequent CONNECTED event does not handle well, resulting in a trap (access violation). Solution: Update the Call State model to capture the held party. This is the same solution for APAR IC26956/Defect 8575 implemented for V 6.2 and V 6.3. APAR IY10698 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. PMR 07292/Defect 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. 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. APAR IY08901/Defect 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. Problom: 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. PMR 48786/Defect 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. PMR 77743/Defect 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. PMR 48742/Defect 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. PMR 01927/Defect 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. PMR 08468/Defect 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. PMR 65936/Defect 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. 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. Defect 8267 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). 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. PMR 48742/Defect 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 CallPath. 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. 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 CEO Callpath Daemon to trap. Solution: Modify code to gracefully handle this condition. Defect 8223 Symptom: KeyCallData bean not returning the correct CallId on the consulted call. Problem: JTAPI daemon does not associate the original callID with the consulted call. Hence the call event sent to the client does not contain the original callID for the consulted call. Solution: Modify the code to handle this condition. JTAPI daemon will associate the original callId with the consulted call during the consult request from the client. This original callId will be sent to the jtapi client in the call event along with the consult response. Defect 8103 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 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. 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. Workaround: None. Solution: Add new return code. 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. 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. APAR IC25084 Symptom: An agent using a Java application (via JTAPI) does not get logged off from SKBR when his java application goes away. Problem: JTAPI daemon does not issue a LOGOFF request to SKBR when it (JTAPI daemon) detects that the java application has gone away. Solution: Modify the code to handle this condition. JTAPI daemon will issue a LOGOFF request to SKBR when it detects that the java application which logged on the SKBR agent has gone away. Defect 8107 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. PMR 70305 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 Callpath Daemon was not monitoring for secondary parties for CONFERENCED events on the SL/1. Also, a logic flaw in the Callpath Daemon code prevented this event from being processed. Workaround: None. Solution: Modify cseblims.cfg file and correct logic problem in Callpath Daemon code. Defect 6625 Switches where the calling party rings and must be answered before the called party will ring are now supported. On some switches, a MakeCall(A,B) results in the calling party A ringing, and must be answered before the called party B will alert. Prior to this fix, an the JTAPI Daemon did not flow events to the application indicating that A was ringing. This resulted in the application not being able to answer A, and thus B would never alert. With this fix, events will flow indicating that A is alerting. Additionally, the response to the MakeCall will flow so that the application is not blocked on the reqeust. Monitor may close prematurely. There is no TRAP or exception evident. The Callpath Monitor must then be be restarted. Defect 6565 The state of a terminal may be incorrect. Scenario is that A calls B and B consults back to A. A hangs up the original call, and B hands up the consultation call. A will report RINGING, even after the application is restarted. Defect 6599 Call State database corruption leads to TRAP. A call from a non-monitored party X to a monitored agent A that is transferred by the agent to a non-monitored party Y results in a call not being cleaned up in the database. Eventually, this will result in a TRAP from the JTAPI Daemon. Defect 6618 Need to process transfer events which do not have the routed_to party Scenario is that agent ext. recieves a call from a RONA huntgroup. The call is forwarded back to the huntgroup on no answer. This results in JTAPI daemon getting a transfer event with no routed_to (the huntgroup in this example) party information. JTAPI does not process this event, leaving the agent ext in the call and corrupting the call state. Defect 6676 The failed transfer corrupts the CSM and eventually leads to a trap. Non-monitored party call a VRU which transfers the call to a non-monitored VDN. This results in a transfer event with no transferred_to party in the event. The processing of transfer event fails corrupting the CSM. PMR 78642 called party is set based on the called party from TADS called party is set based on the called party information in the event. Instead we should be using the DNIS or the dialedNumber to set the called party. Defect 6728 Need to handle when there is no called or the calling party in TADS evt TADS event (transfer and the conference event) does not carry the DNIS or the dialedNumber in the OriginalCallInfo block(for unsolicitated events) Defect 6738 Need to send the original CEO callid for each call to the client. getKey() method of the call object in the JTAPI client (supposed to return the CEO original callid) returns garbage value. Need to store the CEO original callid for each call, and return this id in each call event sent to the client. Defect 7312 Positive response is sent for the Makecall based on a incorrect event The connected event for the inbound call is being used to sent positive response for the makecall. Need to analyze the outstanding requests for the calling and connected party in the CONNECTED event before sending a positive response. Defect 7707 Insufficient memory allocation for the GetProvider request caused overwriting of the stack 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. Defect 7956 ApplicationData is sent across the network as single byte characters. Needs to support double byte. 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 Callpath Enterprise 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 Callpath Enterprise client, the Callpath Enterprise 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. Defect 6526 Support SKBR agents with switches which do not require ACD and/or agentID. 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. DEFECT_8099 (PMR_46144) 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. DEFECT_8071 Abstract: Symptom: Callpath Reporter will lose track of some calls. Problem: New CallID's generated when Callpath Enterprise 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. DEFECT_8049 (PMR_54334) Symptom: A broken TCP connection between a CallPath Enterprise 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 CallPath Enterprise server to daemon connection once a connection is found to be broken. DEFECT_8013 (PMR_52481) 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. DEFECT_8044 (PMR_51649) 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 CallPath 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. DEFECT_7957 (PMR_21873) 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. PMR 42495 Symptom: Adding, Modifying, or commiting updates caused the CPE configurator to crash or the window to silently disappear. This problem is restricted to OS/2 only 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 deleing the CallBlock. 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. 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. DEFECT 7949 Symptom: Added support for Trunk Extensions for CSTA switches. Problem: Report Trunk Extensions as VRU Party types in Callpath Enterprise events. This will allow Callpath Reporter to recognize and track these calls. Workaround: None. Solution: Additional functionality added to Callpath Daemon. Trunk Extensions must be configured appropriately to enable this mechanism. DEFECT 7916 Symptom: Some 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. This has been seen on the Windows/NT operating system. Workaround: Set Method = None in csebcp.ini file. Solution: Limit size of diagnostic messages. DEFECT 7916 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. DEFECT 7745 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 Callpath Interface Daemon component. 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. DEFECT 7919 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 Callpath Interface Daemon component. DEFECT 7689 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 Callpath Interface Daemon component. DEFECT 7622 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 CPE Server that is the source of the NACD operation must have NACD support enabled, and the Callpath switch code must also have NACD support enabled. Workaround: Correct configuration file. Solution: Correct logic in Callpath Interface Daemon component. PMR 12071 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 Callpath Interface Daemon component. Defect 7534 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 Callpath Daemon when ROUTED event handler. PMR 22402 Symptom: Retrieve on held calling party will not work after the called party answers. Problem: Defect 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 CallPath Daemon believes the party is not held. Workaround: None. Solution: Correct logic in Callpath Daemon when called party connects. APAR IX87425 Symptom: Cannot add NACD Queues through CPE Configuration utility. Problem: Defect 7261. The validation logic for adding NACD Queues in the Callpath Daemon is incorrect. This logic is called by the CPE 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 Callpath Daemon logic. APAR IC23169 Symptom: The Callpath 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 Callpath Daemon does not adequetly check for error conditions when initializing RICT. Workaround: When RICT operations are failing, try to stop/start the Callpath Interface. Solution: Improve error checking so that the true state of the RICT connection is displayed. PMR 73356 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. PMR 43550 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. PMR 09272 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. PMR 67472 Symptom: The "SkillsExprn." compound variable does not make the actual contents of _ulQueueSize or _ulQueueTime available to the application. If displayed, the values would be _ULQUEUESIZE and _ULQUEUETIME respectively Problem: The above fields were not being extracted from the "C" structures in the csebrexx.dll. Workaround: None. Solution: Extract the fields from the ACD_INFO structure in the csebrexx.dll Internal 6787 Symptom: While running with a back level Switch Dependent Code on the Lucent G3, it generated a CallPicked event that had the picked_from party equaling the connected party. This cause CPDMON to trap. Problem: This was an interim fix until the G3 dependent code made its fix. However, keeping this fix in the code is good for insurance purposes. Workaround: None. Solution: Report error if picked_from party and connected party are equal in the CallPicked event and continue processing as best we can. PMR 41143 Symptom: With the DMS-100 switch environment and the following scenario results in the situation where a subsequent TRANSFERRED event does not contain the the DBTADS_PARTY_INFO for the external customer. The secenario is: External customer calls and agent A via an ACD, the application performs a TadsRequestExtend() to another agent B, the application completes the Conference by issuing a TadsRequestConference(), the application issues a TadsRequestDisconnect() for A in the A-B leg of the call, agent B finally transfers via the application back to agent A. It is on the final TRANSFERRED event that is generated when B transfers back to A that does not contain the DBTADS_PARTY_INFO structure. This problem only occurs when the customer runs the CPDMON with cseblims.C01. Problem: The CPDMON is not receiving any indication from the switch to tell it to transition the external party into the A-B leg of the call. In other words, since the CPDMON didn't receive a Conference event for the external customer - Agent A - Agent B call, CPDMON did not know to associate the party representation of the external customer with the A - B leg of the call. Workaround: None. Solution: Add support for monitoring Conferenced events from the DMS by updating the cseblims.C01 file. This event is only support by DMS when the STLCONF is issued through an application. The DMS does not support Conferenced events when an agent manually conferences the call. Internal 6997 Symptom: An AGENT_STATUS_EVENT will report the usAgentACDStatus of agent to be either TADS_ACD_STATE_NON_ACD_INT or TADS_ACD_STATE_NON_ACD_INC while processing the CONNECTED_EVENT resulting from the retrieve in the following scenario: Party A calls agent B (B is a member of an ACD Group), B extends to an extension C, B retrieves the A-B leg of the call while C is ALERTING. Problem: The application was informed that B was on in the TADS_ACD_STATE_ACD_CALL state when B connected to A. When C began Alerting the application was informed that B was in the TADS_ACD_STATE_ACD_OTHER state. Once B re-connected to A, the application was informed that B was in either the TADS_ACD_STATE_NON_ACD_INT state or the TADS_ACD_STATE_NON_ACD_INC state depending on A's party type. If party A was internal, the former would be reported. If party A was external, the latter would be reported. Either case was misleading since B was in an ACD_CALL. Workaround: None. Solution: Removed logic that inferred states based on the type of party to which the agent talked. This results in not passing any new usAgentACDStatus states after the TADS_ACD_STATE_OTHER was reported until after the agent disconnects. Internal 6963 Symptom: If a predicitive make call fails on the external party (e.g. the party is busy), the TADS_REJECTED_EVENT contained an incorrect CallId. Problem: This problem occurs when a device (such as a VDN) has more than 1 call active at the same time and one of the calls receives a TADS_REJECTED_EVENT as the first event for a call. This may happen when a predicitive makecall reaches a busy called device. In this scenario, the CallId presented for the TADS_REJECTED_EVENT will be the CallId of one of the other calls at the device. Workaround: None. Solution: Code logic updated to select the correct CallId when generating the TADS_REJECTED_EVENT. PMR 74635 Symptom: Diagview daemon in AIX abends trying to view shared memory of process that abended. Problem: When a process abends (core dumps) in AIX, the shared memory segment still remains and should be able to be viewed by csebdbgw. This ability was broken by a change that should have been limited to the WinNT and OS/2 platforms. Workaround: None. Solution: csebdbgw now successfully attaches to shared memory of a process that core dumped. PMR 09162 Symptom: The TCP connection between the CallPath Enterprise Server and an associated daemon breaks for no apparent reason. Shortly thereafter the server traps in AZAOM30.DLL. Problem: The daemon receives a 0 length message from its server connection. In response the daemon assumes the connection has gone away and closes the connection. Once the server discovers that the connection to the daemon is broken he attempts to cleanup and ends up overwriting memory. Workaround: None Solution: Changed code to not treat a "no data" condition on a TCP socket receive call as an error. Corrected the memory overwite problem. PMR 42104 Symptom: In NT, occasionally the CallPath Enterprise Client traps after restarting an associated CallPath Enterprise Server. This problem can also occur in the server if associated daemons are stopped and started multiple times. Problem: The extents of an array holding connection information is exceeded. This results in memory being corrupted and the trap. Workaround: None Solution: Changed code to not use the socket handle as an index into the connection information array. Instead, hashing is used to locate array entries. PMR 10452 Symptom: The DMS Switch Dependent code will occasionally send a Call Routed(QUEUE_CLEANUP) event where the contents of calling party structure is also the same contents in the routed_to party structure. When this occurs the CP Interface Deamon will trap. Problem: Defect 6893 (Toronto Defect 4839). Since the calling party structure equals the routed_to party structure the Call Routed processing attempts to delete the same CID entry twice. This causes the trap. The fix is to only delete the routed_from party on the QUEUE_CLEANUP route. This problem has only appeared with the DMS-100 running Euro BCS 3 and CEO 2.1 although we could not duplicate it in our lab. It is also fixed in 2.21 just in case. Although the switch dependent code sends this message with an erroneous routed_to, the CP Interface Deamon should handle this error condition gracefully. It now does just that by only deleting the routed_from party. Workaround: None. Solution: Only delete the CID entry associated with the Routed_from party when processing a Call Routed (QUEUE_CLEANUP) event. PMR 09206 Symptom: An occasional performance problem on CallPath Enterprise Server when a client goes away. Problem: CallPath Enterprise Clients are sending (in error) TADS_SYSTEM_EVENTS to the server. The server is fooled into treating these clients as daemons, and when one of these clients goes away, the server sends a TADS_SYSTEM_EVENT to all clients monitoring for system events. This causes a big performance problem when hundreds of clients are attached. Workaround: None Solution: Modified the server code to not be fooled into treating regular clients as daemons. Modified the client code to not send TADS_SYSTEM_EVENTS to the server. APAR IX84753 Symptom: A Request_Instructions event from Callpath will not get translated to a Routed_Trigger event following the processing of a reused Network CallID. Problem: PMR 63421, Defect 6810 (Toronto Defect 4711, 4822). This problem applies to Nortel-SL/1 switches utilizing NACD support. When a Network CallID is reused, csebcp will cleanup up the Bridge Line for NACD processing, but does not check for nor clean up any old calls that reference that Network CallID. This will result in an error in subsequent Routed and Request_Instructions event processing, ultimately leading to a valid Routed_Trigger event not getting generated and sent to a monitoring application(s). Workaround: None. Solution: Clean up all calls that reference re-used Network CallIDs. PMR 53131 Symptom: Call Reporter loses track of a call that is ICT'd between two sites. Problem: If an external party calls into a DMS and eventually that call is ICT'ed (Intelligent Call Transfer) out of the DMS to another enterprise server, Call Reporter is not notified that the call has left the local DMS switch. This was fixed by generating a Call Stats event indicating that the calling and routed two party disconnected from the local DMS switch. The calling and routed-to numbers are remote numbers that an application could not monitor. Therefore an application must monitor the CALL STATS event because a Disconnected event couldn't be sent to applications since a Disconnected event requires an application to be monitoring at least one of the extensions carried in the Disconnected event. 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 Enterprise 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 Enterprise 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. 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. 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. APAR IX82684 Symptom: Callpath Daemon (csebcp.exe) Traps on CALL_PICKED Event. Problem: In CPE Daemon, if a Call_Picked event is received where the Connecting Party CID already exists, the CPE Daemon will trap. This is usually a secondary effect from a Callpath Switch Dependent code problem. Workaround: Correct event flow from Callpath. Solution: Correct logic in CPE Daemon Call_Picked Event Handler so that it no longer attempts to use a NULL pointer. PMR 09714 Symptom: The CallPath Enterprise Server may trap when a connected client ends suddenly without closing its connection to the server. A common scenerio is when a machine running the CallPath Enterprise Client is rebooted. Problem: Memory used to store information about the connection is freed once the server discovers that the connection is broken. The trap occurs when another thread, not aware of this memory being freed, references the memory. Workaround: None. Solution: Mofified code to properly handle clean up of a broken connection. PMR 32718 Symptom: Enterprise Client, Server, or a Daemon could abend during some shutdown scenarios. Usually this would occur during a user-invoked shutdown. Occsasionally, it would happen during an attempt at orderly shutdown due to a terminating error. Problem: 1) Attempting to shutdown a client, server, or daemon that was started with the nodisplay option in certain AIX environments by using the SIGTERM signal. 2) Timing problem between shutdown of NetLayer and shutdown of DispatcherLayer. 3) Attempts to shutdown a daemon using the daemon stop() method. Workaround: None. Solution: Several timing and cleanup problems in shutdown logic were removed. Files in service: csebclnt.txt csebclnt.txt csebserv.txt csebserv.txt readme.jta bin\config.jar bin\csebclnt.exe bin\csebcon.exe bin\csebcp.exe bin\csebdbgw.exe bin\csebjtpi.exe bin\csebprof.exe bin\csebserv.exe bin\csebxmsg.exe conf\csebhint.cfg conf\cseblims.c01 conf\cseblims.cfg conf\csebrem.cfg dll\csebapi.dll dll\csebbase.dll dll\csebdmon.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 dll\csebintf.dll bin\csebmon.exe conf\cseblims.c02 conf\profile\prfhcsta.ini