Avaya AuraTM Application Enablement Services R5.

2 Server and Client Release Notes

October 2010

INTRODUCTION
This document introduces the Generally Available release of the Application Enablement (AE) Services Release 5.2 and describes important notes and known issues. The Avaya AuraTM Application Enablement Services Overview has a complete list of 5.2 features. Whats Changed in AE Services 5.2? In addition to the AE Services Bundled Offer and Software Only Offer, Avaya is introducing the Avaya AuraTM AE Services on System Platform Offer. The new offer provides increased manageability, reliability and serviceability. The AE Services on System Platform solution provides the optional High Availability Failover feature. This feature allows two identical servers that can be addressed and administered as a single entity. If one server fails, the second automatically becomes available to client applications. An SNMP Agent has been incorporated into the AE Server which supports SNMP v1, v2c, and v3. This agent provides access to SNMP related system performance and metrics associated with the AE Server and AE Services (TSAPI, CVLAN, DLG, DMCC and the Transport Layer). In addition, a new set of alarms and SNMP traps/notifications have been added. Support of the Processor Ethernet (PE) connection on the S87XX and S8800 servers using Communication Manager 5.2.1 (or later) for AE Services transport link data. By adding support for S87xx and S8800, AE Services now supports PE connections on all Communication Manager platforms (S8300, S8400, S85xx, and S8800). CLAN cards are no longer required for nonESS/LSP configurations. Increased CTI bandwidth on Communication Manager and AE Services (when the Processor Ethernet connection is employed) from 720 to 1,000 messages per second. Thirty-day License Grace Period. IBM Sametime 8.0.2 is now supported. SMS Schema Enhancements a new XML I/O interface and Unicode support. Release 5.2 October 2010

AE Services is now available for customer downloads from the Avaya Product License and Delivery system. DMCC enhancements: o DMCC Service recovery allows DMCC to persist session, device, monitor and Time to Service H.323 registration states during normal operations. If the DMCC service is restarted abnormally, it will restore the working state for a client application to continue operating with minimal interruption. DMCC registration recovery requires Communication Manger 5.2.1. o UTF-8 Unicode support in DMCC. o Advanced authentication and authorization policies. o Flexible application session characteristics. o Support for Communication Manager 5.2.1 and later Time to Service H.323 Registration.

Microsoft OCS 2007 R2 is now supported. AE Services 5.2 supports Red Hat Enterprise Linux 5.0 Update 3. AE Services 5.2 is compatible with the following Bundled Servers: o IBM x306m (S8500C) o Dell 1950 (S8510) o IBM x3550 M2 (S8800)

SOFTWARE RELEASE VERSIONS

Application Enablement Services Application TM Avaya Aura Application Enablement Services 5.2 CVLAN Client Linux Avaya AuraTM Application Enablement Services 5.2 CVLAN Client Windows Avaya AuraTM Application Enablement Services 5.2 TSAPI Client Linux Avaya AuraTM Application Enablement Services 5.2 TSAPI Client MS Windows Avaya AuraTM Application Enablement Services 5.2 TSAPI SDK Linux Avaya AuraTM Application Enablement Services 5.2 TSAPI SDK MS Windows Avaya AuraTM Application Enablement Services 5.2 JTAPI SDK File Name cvlan-client-linux-5.2-454.i386.rpm cvlan-client-win32-5.2-454.zip tsapi-client-linux-5.2-454.i386.rpm tsapi-client-win32-5.2-454.zip tsapi-sdk-linux-5.2-454.i386.rpm tsapi-sdk-win32-5.2-454.zip jtapi-sdk-5.2.0.454.zip

Release 5.2 October 2010

Application Enablement Services Application Avaya AuraTM Application Enablement Services 5.2 Web Service - System Management SDK Avaya AuraTM Application Enablement Services 5.2 DMCC .Net SDK Avaya AuraTM Application Enablement Services 5.2 Web Services - Telephony SDK Avaya AuraTM Application Enablement Services 5.2 DMCC XML SDK Avaya AuraTM Application Enablement Services 5.2 DMCC Java SDK Avaya AuraTM Application Enablement Services 5.2 MIBs Avaya AuraTM Application Enablement Services 5.2 Software Only Avaya AuraTM Application Enablement Services 5.2 Hardware Bundled Upgrade fo S8500/S8510 Avaya AuraTM Application Enablement Services 5.2 on System Platform

File Name smssvc-sdk-5.2.0.1045.zip

dmcc-dotnet-sdk-5.2.0.11.zip telsvc-sdk-5.2.0.1045.zip cmapixml-sdk-5.2.0.1045.zip cmapijava-sdk-5.2.0.1045.zip aesvcs-product-mibs-5.2.0.1045.zip swonly-r5-2-0-98-20091106.iso bundled-r5-2-0-98-20091106.iso

sp-aes-r5-2-0-98.iso

IMPORTANT NOTES
AE Services 5.2 is compatible with the following Communication Manager Releases and Platforms: o Communication Manager 4.x (S8300, S8400, S8500, S87xx) o Communication Manager 5.0 (S8300, S8400, S8500, S87xx) o Communication Manager 5.1 (S8300, S8400, S85xx, S87xx) o Communication Manager 5.2 (S8300, S8400, S85xx, S87xx) o Communication Manager 5.2.1 (S8300, S8400, S85xx, S87xx, S8800) Communication Manager 5.2.1 is compatible with the following AE Services Releases: o AE Services 4.x.x o AE Services 5.2 MAPD is NOT supported beginning with Communication Manager 5.0

Release 5.2 October 2010

Release History: Date Build 03/2007 47-3 06/2007 50-1 12/2007 31-2 04/2008 4.1.16 05/2008 19-4 08/2008 20-5 06/2009 31 09/2009 33 11/2009 98

Change(s) General Availability R4.0 General Availability R4.0.1 General Availability R4.1 General Availability R4.1.1 JTAPI Client/SDK General Availability R4.2 Service Pack R4.2.1 Service Pack R4.2.2 Service Pack R4.2.3 General Availability R5.2

Release 5.2 October 2010

KNOWN ISSUES AND WORKAROUNDS

For Installation and/or Upgrade

1. After the AE Services installation or upgrade completes, wait 10 minutes and then login to the server. 2. As the root user, check to see if the configuration has completed by running the following command: ls l /usr/share/tomcat5/webapps/CS-SDAS/WEB-INF/web.xml If the file is not yet there, the following command will return: ls: /usr/share/tomcat5/webapps/CS-SDAS/WEB-INF/web.xml: No such file or directory. Wait 1 minute and run the command again until the configuration has copied the file to this location. If the file is there, the command will return the full path and filename and the configuration is completed, for example: -rw-r--r-- 1 tomcat5 459 Feb 13 2006 /usr/share/tomcat5/webapps/CS-SDAS/WEB-INF/web.xml 3. Run the following as root user: service DBService restart 4. Run the following as root user: service aesvcs restart

AE Services Bundled upgrade from release 3.x must follow one of the following options BEFORE upgrading!
Option 1: Run a pre-upgrade script Download the Avaya AuraTM Application Enablement Services 3.x to 5.2 Upgrade Script from the Avaya Product License and Delivery System. Upload the zip file to the 3.x AES server in the /tmp directory. Login to the AES console as sroot $ cd /tmp $ unzip aes-52-preupgrade.zip $ cd aes-52-preupgrade $ chmod 755 aesUserGroup.sh $ ./aesUserGroup.sh

Release 5.2 October 2010

OR Option 2: Perform a two step upgrade. First upgrade from AES 3.x to AES 4.2.2. From the console make the upgrade permanent by executing the following command as sroot: $upgrade -p Then upgrade from AES 4.2.2 to AES 5.2.

AE Services Manual Database restore from 3.x release requires OAM re-login.
When manually restoring a 3.x database from the AES OAM, be sure to log-out after the restore and then log back in before performing any administration. This is required to synchronize user passwords and if not performed, certain administrative functions such as User Management may not be available from OAM until the re-login.

AE Services Bundled and Software Only installation - "User Management" link is missing from the OAM.
Restart aesvcs to fix this problem. From the OAM: Maintenance | Service Controller | Restart AE Server

System Platform Webconsole Backup/Restore fails in High Availability configuration.

If AE Services is configured in a High Availably (fail-over) mode, then do not use the WebConsole on CDOM to perform an AE Services backup and restore. Instead, use the AE Services management console to perform the backup and restore. This feature can be found on the AE Services OAM under Maintenance | Server Data.

AE Services on System Platform Product ID Update

When the product ID (productid) is updated in the System Platform WebConsole, (AFTER a complete installation), it will be necessary to execute (as sroot on the command line) the call service syslogreader restart in order for the updated product ID to be used for alarms.

AE Services on System Platform IP Address is not Populated during Installation

After installing AE Services on Service Platform, verify that the network IP addresses are set correctly by logging into OAM and selecting "Networking | AE Service IP (Local IP)". This OAM page will display the following message if the network IP addresses were not detected at installation time: "Unknown Client IP address exists in the Database. Unknown Switch IP address exists in the Database. Release 5.2 October 2010

Unknown Media IP address exists in the Database." To correct this problem, reboot the Linux operating system by navigating to Maintenance | Service Controller from OAM. Click on "Restart Linux", then "restart" again to confirm.

AE Services on System Platform Server High Availability Installation

Do not set the 2nd servers IP address while configuring the Dual NIC for the AE Services domain during the System Platform installation or during the WebConsole setup. The IP address of the 2nd server should be left blank and entered through the WebConsole after the installation is complete.

AE Services on System Platform Server High Availability Failover may not occur Heartbeat Ping Service cannot Communicate with the Gateway
The heartbeat is configured to use the ping service between the High Availability nodes and the gateway using unicast UDP communication on port 694. The heartbeats ping service to the gateway should only use ICMP requests which dont require port 694 to be opened. The following entry: "ucast avpublic <default dateway IP> # Public PING target (switch)" should be removed from the ha.cf file located in the following directories /etc/ha.d and /opt/avaya/ha/resources on both the active and standby boxes. Removing this line will result in the correct ping service operation. To apply these changes, follow the steps outlined below. The System Platform High Availability Failover must be stopped and is a service interrupting operation that should be scheduled accordingly. 1. Stop High Availability Failover Mode from the System Platform WebConsole 2. Log in to the preferred Domain-0 and su to root 3. Execute following command: sed -i.ucast_fix -e '/# Public PING target (switch)/d' /opt/avaya/ha/resources/ha.cf 4. To confirm the entry was successfully removed, execute the following command and no output should be returned. cat /opt/avaya/ha/resources/ha.cf | grep Public 5. Repeat steps 2, 3 and 4 for the standby Domain-0 6. Start High Availability Failover Mode from preferred System Platform WebConsole

Release 5.2 October 2010

AE Services on System Platform Server High Availability Failover will not occur if the Gateway Firewall Rules Drop Heartbeats Ping Packets
Heartbeat uses the utility service "pingd" to monitor the ability of cluster nodes to communicate to the network by sending an ICMP request from each node (Primary and Standby Domain-0) to the default network gateway and expects a response back from the gateway. This service sets payload with nodeidentifying data and checks that the data in replied packet payload are correct. The size of the ICMP ping packets is in the range of 132 - 256 bytes. If firewall rules are applied against the ping service (at the gateway), specifically packet size restriction, it should allow for packet sizes up to 256 bytes. If the packet size restrictions are applied, ensure the packet size is 256 bytes.

AE Services on System Platform Server High Availability Failover Re-establishing a Node into a High Availability Cluster Requires Manual Configuration
When the active server is running in standalone mode, the process of incorporating the failed server into the High Availability cluster to work in High Availability mode will not work from the WebConsole. Specifically, Stop Failover Mode will fail. The WebConsole is redirected to the reboot page, but it is not redirected to the login page. A series of manual steps needs to be executed to bring the standby node back online to function in the High Availability mode. Please note that this process depends on the node type (preferred or standby) to be re-established into the High Availability cluster again. Specifically, steps 12-17 are only needed when the node to be re-established is the preferred node. To re-enable the reinstalled standby node in the High Availability system: 1. Open SSH session to the active Domain-0 and su to root: su Password: 2. From SSH session to the active Domain-0 execute: /opt/avaya/ha/scripts/crmutil stop-domain --name dom0 3. Ensure that all resources except STONITH resources are stopped - from SSH session to the active Domain-0 execute: a. crm_mon -1 ============ Last updated: Thu Nov 26 15:40:16 2009 Current DC: vspha1.example.com (24b5c8b5-0767-4365-9e2420dc9bc48ed1) Release 5.2 October 2010

Version: 1.0.2-c02b459053bfa44d509a2a0e0247b291d93662b7 2 Nodes configured. 3 Resources configured. ============ Node: vspha1.example.com (24b5c8b5-0767-4365-9e2420dc9bc48ed1): online Node: vspha2.example.com (c861c9d0-9209-45cb-a3a7d590df1dd4be): OFFLINE Clone Set: fencing stonith-resource:0 (stonith:null): Started vspha1.example.com stonith-resource:1 (stonith:null): Stopped b. xm list Name Domain-0 udom aes

ID Mem VCPUs State Time(s) 0 512 4 r----- 88.0 1024 1 276.3

c. cat /proc/drbd version: 8.3.2 (api:88/proto:86-90) GIT-hash: dd7985327f146f33b86d4bff5ca8c94234ce840e build by mockbuild@v20z-x86-64.home.local, 2009-08-29 14:08:07 0: cs:WFConnection ro:Secondary/Unknown ds:UpToDate/Outdated C r---ns:0 nr:0 dw:4120 dr:1852 al:1 bm:4 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:8 1: cs:WFConnection ro:Secondary/Unknown ds:UpToDate/Outdated C r---ns:0 nr:0 dw:197376 dr:388270 al:123 bm:308 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:19876 2: cs:WFConnection ro:Secondary/Unknown ds:UpToDate/Outdated C r---ns:0 nr:0 dw:4112 dr:546 al:1 bm:4 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:4 3: cs:WFConnection ro:Secondary/Unknown ds:UpToDate/Outdated C r---ns:0 nr:0 dw:219612 dr:25466 al:26 bm:55 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:47556 4. From SSH session to the active Domain-0 execute: a. /opt/avaya/ha/scripts/stop_vspha.sh primary b. mount | grep /template-env /dev/mapper/VolGroup00-lv_tmpl_env on /template-env type ext3 (rw) 5. From SSH session to the active Domain-0 execute: Release 5.2 October 2010

a. /opt/avaya/ha/scripts/crmutil remove-domain --name dom0 b. crm_mon -1 ============ Last updated: Thu Nov 26 15:46:06 2009 Current DC: vspha1.example.com (24b5c8b5-0767-4365-9e2420dc9bc48ed1) 2 Nodes configured. 0 Resources configured. ============ Node: vspha1.example.com (24b5c8b5-0767-4365-9e2420dc9bc48ed1): online Node: vspha2.example.com (c861c9d0-9209-45cb-a3a7d590df1dd4be): OFFLINE Failed actions: udom-drbd-udom0_start_0 (node=vspha1.example.com, call=29, rc=1, status=complete): unknown error 6. From SSH session to the active Domain-0 execute: a. PEER_NAME=`crm_mon -1 | grep OFFLINE | awk '{print $2}'` b. echo $PEER_NAME vspha2.example.com 7. From SSH session to the active Domain-0 execute: a. crm node delete $PEER_NAME b. crm_mon -1 ============ Last updated: Thu Nov 26 15:50:50 2009 Current DC: vspha1.example.com (24b5c8b5-0767-4365-9e2420dc9bc48ed1) 1 Nodes configured. 0 Resources configured. ============ Node: vspha1.example.com (24b5c8b5-0767-4365-9e2420dc9bc48ed1): online 8. From SSH session to the active Domain-0 execute: a. service heartbeat stop b. crm_mon -1 Connection to cluster failed: connection failed

Release 5.2 October 2010

10

9. From SSH session to the active Domain-0 execute: a. rm -f /var/lib/heartbeat/pengine/* b. rm -f /var/lib/heartbeat/crm/* c. rm -f /var/lib/heartbeat/hb_* d. rm -f /var/lib/heartbeat/*hostcache e. ll /var/lib/heartbeat/* prw------- 1 root root 0 Nov 26 15:50 /var/lib/heartbeat/fifo /var/lib/heartbeat/cores: total 24 drwx------ 2 hacluster haclient 4096 Nov 20 2008 hacluster drwx------ 2 nobody nobody 4096 Nov 20 2008 nobody drwx------ 2 root root 4096 Nov 20 2008 root /var/lib/heartbeat/crm: total 0 /var/lib/heartbeat/pengine: total 0 10. From SSH session to the active Domain-0 execute: a. service drbd stop Stopping all DRBD resources: . b. cat /proc/drbd cat: /proc/drbd: No such file or directory 11. From SSH session to the active Domain-0 execute: a. sed -i e 's/GLOBAL_STATUS=STARTED/GLOBAL_STATUS=CONFIGURE D/' /opt/avaya/ha/scripts/vspha.conf b. cat /opt/avaya/ha/scripts/vspha.conf | grep GLOBAL_STATUS GLOBAL_STATUS=CONFIGURED 12. Check whether currently active node is preferred or standby node. If the node is preferred node, go to step 18. If the node is not preferred, continue with all of the following steps. The user should not try to reinstall the preferred node unless instructed to do so. To check if the currently active node is the preferred node, from SSH session to the active Domain-0 execute as root: a. source /opt/avaya/ha/scripts/vspha.conf b. ifconfig $NETWORK_INTERFACE | grep " addr:$PRI_IP_ADDR " If this command did not return any output, currently active node is NOT preferred node - perform steps 13-17.

Release 5.2 October 2010

11

If this command returned output with IP address, broadcast and netmask currently active node IS preferred node do not perform steps 13-17 and continue directly to step 18. 13. From SSH session to the active Domain-0 execute: a. echo $SEC_UDOM_MAC_ADDR An example output: 00:16:3e:28:18:fe Make a note of this MAC address. It will be referenced as <MAC_ADDR> in following steps. b. echo $SEC_UDOM_IP_ADDR An example output: 135.64.30.44 Make a note of this IP address. It will be referenced as <IP_ADDR> in following steps. 14. Swap the node roles. From the SSH session to the active Domain-0 execute: a. sed -i -e '/PRI_[^U]/s/PRI_/TMP_/' /opt/avaya/ha/scripts/vspha.conf b. sed -i -e '/SEC_[^U]/s/SEC_/PRI_/' /opt/avaya/ha/scripts/vspha.conf c. sed -i -e '/TMP_/s/TMP_/SEC_/' /opt/avaya/ha/scripts/vspha.conf Note: The active node has now become the new preferred node. 15. Update the reference to the current Domain-0 in the SSL key file. From the SSH session to the active Domain-0 execute: sed -i -e "/tomcat@/s#/$PRI_FULL_NAME#/$SEC_FULL_NAME#g" /root/.ssh/authorized_keys 16. Reinstall the preferred node with the same System Platform version as currently active node. If it was reinstalled before this point, repeat the installation as the previous installation has failed. When reinstalling the formerly preferred failed node, ensure to use standby CDOM IP address (value referenced as <IP_ADDR> retrieved in step 13.-b.) as CDOM still uses preferred node CDOM IP address. 17. When preferred node is reinstalled and its WebConsole is accessible, log in to its Domain-0 as admin user and execute following sequence of commands. Please replace every occurrence of <MAC_ADDR> with the real value of the MAC address retrieved in step 13(a) when typing the commands. a. su b. sed -i -e '/^vif /s/mac=00:16:3e:[^,]*/mac=<MAC_ADDR>/' /etc/xen/udom c. ssh cdom.vsp d. sed -i -e '/^HWADDR=/a\MACADDR=<MAC_ADDR>' /etc/sysconfig/network-scripts/ifcfg-eth0

Release 5.2 October 2010

12

e. sed -i -e 's/^HWADDR=/#HWADDR=/' /etc/sysconfig/networkscripts/ifcfg-eth0 f. ifdown eth0; ifup eth0 g. Please ensure that you can access WebConsole using <IP_ADDR> IP address. 18. From SSH session to Domain-0 on active node execute: xm start udom 19. The WebConsole of the active node should redirect after couple of minutes. After the redirect, perform the following: a. Log on to WebConsole as admin b. Go to Server Management -> Failover c. Click "Remove Failover" button and confirm the warning 20. From SSH session to Domain-0 on active node execute as root: a. ssh cdom.vsp sed -i -e '/dom0-standby.vsp/d' /etc/hosts b. ssh cdom.vsp cat /etc/hosts | grep dom0 <Dom-0 IP> dom0.vsp 21. From SSH session to Domain-0 on active node execute as root: a. sed -i -e "/^$PEER_NAME,/d" /root/.ssh/known_hosts b. cat /root/.ssh/known_hosts | grep $PEER_NAME <no output expected> 22. From SSH session to Domain-0 on active node execute as root: a. sed -i -e "/root@$PEER_NAME$/d" /root/.ssh/authorized_keys b. cat /root/.ssh/authorized_keys | grep $PEER_NAME <no output expected> 23. On the WebConsole of the active node logged in as admin: a. Go to Server Management | Failover b. Click "Configure Failover" button c. Provide IP address of remote (reinstalled) node cdom d. Provide password for user 'admin' e. Ensure that 'Remote Reboot' option is disabled f. Click Configure button 24. On the WebConsole of the active node logged in as admin: a. Go to Server Management | Failover b. Click "Start Failover Mode" button and confirm warning c. WebConsole is redirected to reboot page d. After couple of minutes it is redirected to login page e. Log in to WebConsole as admin again f. Check the progress of DRBD sync process

Release 5.2 October 2010

13

AE Services on System Platform Server When the System Event Log Cache Reaches Capacity, New Events will not be Logged
There is no automated mechanism in place to clear the System Event Log cache when it becomes full. New events will not be logged if the cache isnt cleared. The maximum number of entries is 512. Manual steps to clear the cache and preserve old entries are as follows: 1. Log into Domain-0 as root account # su root Password:<roots password> 2. List cached System Event Log events. The following command will display all of the events available in the cache: # ipmitool sel list 3. Backup all the System Event Log events to /root/sel_events_1.txt in case to be referred to in the future : # ipmitool sel list > /root/sel_events_1.txt 4. Empty System Event Log cache # ipmitool sel clear 5. Verify whether the System Event Log entry is empty. The output of this command will be much less than the output in step b) # ipmitool sel list The System Event Log entry may be full again in the future. To avoid this from happening, administrators may consider adding the tasks described above to cron as shown in step 6. 6. Add a cron job to clear System Event Log entries every 5 minutes # crontab -e At this point, vi should be launched and some existing cron jobs may be displayed. PATH=/opt/avaya/vsp/bin:/bin:/usr/bin PYTHONPATH=/opt/avaya/ha/lib Release 5.2 October 2010

14

*/5 * * * * /opt/avaya/ha/scripts/monitor-hardware */2 * * * * find /var/lib/xen/boot_* -mmin +1 delete Please dont change any existing lines! Instead, append the following line to the end of the file: */5 * * * * /usr/bin/ipmitool sel clear The final result of the file will be displayed as follows: PATH=/opt/avaya/vsp/bin:/bin:/usr/bin PYTHONPATH=/opt/avaya/ha/lib */5 * * * * /opt/avaya/ha/scripts/monitor-hardware */2 * * * * find /var/lib/xen/boot_* -mmin +1 delete */5 * * * * /usr/bin/ipmitool sel clear 7. Save the changes.

AE Services on System Platform Server Backup History shows Successful even after a File Transfer Fails
If backup from the web console fails to transfer the backup archive to an SFTP server or email to a user it still shows the backup status as Successful. The backup status history doesnt reflect the status of the backup archive transfer, it only reflects whether the backup was run successfully on the System Platform server and the backup archive was created locally in CDOM under vspdata/backup/archive/. If a backup is unable to transfer the backup archive to an SFTP server or email to a user, it will send an alarm to the Avaya SAL gateway or NMS if it is configured. If the SAL gateway and NMS are not configured, then the user can review the alarm log file to check for any Backup transfer errors. For example: <11>Dec 10 10:41:49 udom3.du.rnd.avaya.com vspwebconsole[23276]: +00:00 2011 116 1 com.avaya.vsp | 1 com.avaya.vsp.webconsole O_AVPC22017 Backup archive backup_udom3_2011_12_11_00_41_43.tgz could not be sent on server 135.64.29.97.

CVLAN Services Does Not Display Online

If there are no CVLAN links administered, the CVLAN Service will appear as "OFFLINE" on both the AE Services summary page and the Status summary page of the AE Services Management Console. The status will change to "ONLINE" after you administer at least one CVLAN link. Release 5.2 October 2010

15

DLG Links
DLG links may be OFFLINE after recovery from an abnormal shutdown.

DLG Service Does Not Display Online

If there are no DLG links administered, the DLG Service will appear as "OFFLINE" on both the AE Services summary page and the Status summary page of the AE Services Management Console. The status will change to "ONLINE" after you administer at least one DLG link.

DMCC New CSTA Private Error Code

A new CSTA private error code has been added for DMCC clients to resolve a request timeout when the request contains invalid UTF-8. For client applications that use the Java SDK, the error will appear as a com.avaya.csta.errors.PayloadDecodeException. Users of the XML SDK will see this as a CSTAErrorCode with a privateError code value of 8.

Local WebLM Server Port Number

For AE Services Software-Only servers: If you have upgraded to AE Services 5.2 from an earlier release of AE Services, your local WebLM server may be configured to use port 443. Most AE Services customers will see improved WebLM performance if the port number is changed from 443 to 8443. Use this procedure to change the port number for your local WebLM server to 8443: 1. Use a web browser to log into the Application Enablement Services Management Console. 2. Select "Licensing | WebLM Server Address". 3. If the value of the WebLM IP Address is 127.0.0.1 and the value of the WebLM Port is 443, change the value of the WebLM Port to 8443 and click on "Apply Changes". 4. When the confirmation screen is displayed, click on "Apply". 5. For the Bundled or AE Services on System Platform Server offers, select Security | Standard Reserved Ports. 6. If the TOMCAT HTTPS 8443 row is not checked, then click it and click Apply. After changing the WebLM Port to 443, you must restart several of the AE Services: 1. Select "Maintenance | Service Controller". 2. Set the check boxes for "ASAI Link Manager", "CVLAN Service", "DLG Service", "Transport Layer Service", and "TSAPI Service", and click on "Restart Service". 3. When the confirmation screen is displayed, click on "Restart". Release 5.2 October 2010

16

 OCS Integration and Microsoft Certificate Authorities (CA)

When using Microsoft as the CA, Microsoft recommends using an Enterprise CA. The Enterprise CA template used to create the AE Services certificate must have the Enhanced Key Usage (EKU) field specified appropriately (Server and Client Auth or neither). The LCS/OCS AE Services integration uses Mutual TLS (MTLS) to authenticate server-to-server SIP communication. On an MTLS connection, the server originating a message and the server receiving it exchange certificates from a mutually trusted CA to prove the identity of each server to the other. The server certificate used for MTLS on both servers must either not specify an Extended Key Usage (EKU) or specify an EKU for Server and Client Auth. When the EKU is not specified the certificate is not restricted to a particular usage. However when the Key Usage field is specified and the EKU is specified as Server and Client Auth, the certificate can only be used by the server for mutual server and client based authentication purposes. If an EKU with only Server Auth is specified, in this scenario, the connecting server certificate will fail authentication and the MTLS connection will not be established. The Standalone CA, which may also be used (but is not Microsoft recommended), does not provide configurable templates including some additional features and must adhere to the same certificate generation rules in regards to the EKU field. Note that this statement doesn't preclude administrators from using nonMicrosoft CAs (e.g. VeriSign).

Process to Change the Server IP Address

If the IP address of an AE Services server is changed without stopping the server, or if the IP address is changed and then an attempt is made to set the new address through the web pages without stopping the server (which is using the connection), an error message will be displayed. The error message will appear on the Local IP web page and indicate that the database entry for the IP address does not match the IP address configured on the server. The proper procedure to change the IP address is as follows: For AE Services Bundled server: 1. Log in as sroot. 2. Execute the command service aesvcs stop 3. Execute the command /opt/mvap/bin/netconfig to bring up GUI. 4. Enter/Modify IP address(es) per NIC interface (Make sure Enable boxes are checked), and save/exit by OK button.

Release 5.2 October 2010

17

5. Re-login as sroot with new IP address if administering remotely. Issue service network restart (This step is pre-cautionary). 6. Log into OAM AE Server Administration using new IP address of AE SERVICES server. (Note: If OAM web page is not responding in proper time, issue service tomcat5 restart and try again). 7. Go to Administration | Network Configuration | Local IP and set the new IP address(es) for all Connectivity entries. 8. Execute the script /opt/mvap/bin/setAlarmSvcUpgrade.sh . 9. Go to Maintenance | Service Controller and apply Restart AE Server button. 10. Make sure all services are in Running state, and connection state to switch(es) is functional. For AE Services Software-Only server: 1. Log in as root. 2. Execute the command /sbin/service aesvcs stop 3. *** The customer is responsible for the change, but Avaya highly recommends using Linux utility such as /usr/bin/system-config-network if using Redhat Release 4 or 5. /etc/hosts file must be updated with new IP address(es). Issue /sbin/service network restart (This step is precautionary). *** 4. Log into OAM AE Server Administration using new IP address of AE Services server. (Note: If OAM web page is not responding in proper time, issue /sbin/service tomcat5 restart and try again). 5. Go to Administration | Network Configuration -> Local IP and set the new IP address(es) for all Connectivity entries. 6. Execute the script /opt/mvap/bin/setAlarmSvcUpgrade.sh. 7. Go to Maintenance | Service Controller and apply Restart AE Server button. 8. Make sure all services are in Running state, and connection state to switch(es) is functional. Note: If the OAM page cannot be accessed, check status of httpd/tomcat5 processes via /sbin/service httpd status and /sbin/service tomcat5 status, and start if not running.

Process to Change the Server Date and Time

When the server time is changed by more than five minutes, several of the AE Services must be restarted. While these services will be restarted on their own, the following procedure is recommended for changing the AE Services Bundled or Software-Only server time: 1. Log into the AE Services Management Console. 2. Select "Maintenance | Service Controller". 3. Set the check box for the appropriate service (TSAPI, Transport, asailink, DLG or CVLAN), and then click on "Stop". Release 5.2 October 2010

18

4. When the confirmation screen is displayed, click on "Stop". 5. Select "Maintenance | Date Time/NTP Service", make the appropriate date/time changes on the web-page and click "Apply Changes". 6. When the confirmation screen is displayed, click on "Apply". 7. Select "Maintenance | Service Controller". 8. Set the check box for the appropriate service (TSAPI, Transport, asailink, DLG or CVLAN), and then click on "Start". For the AE Services on System Platform server, refer to the Administering Avaya AuraTM System Platform at http://support.avaya.com/css/P8/documents/100068114

Reserving TSAPI User Licenses

After installing or upgrading to AE Services 5.2, Avaya recommends that you follow this procedure to ensure that the TSAPI Service starts successfully after a system reboot and to optimize the performance of the TSAPI Service: 1. Determine your WebLM configuration model: In a typical AE Services configuration, a standard license file is installed on each AE Services server, and the licenses in that license file are acquired through a local WebLM server running on the AE Services server or CDOM for the AE Services on System Platform Server. However, other configurations are also possible: Multiple AE Services servers may be configured to acquire their feature licenses from a single WebLM server where a standard license file is installed. In this configuration, feature licenses can "float" from one AE Services server to another as they are needed. With Enterprise Wide Licensing, an enterprise license file is installed on a master WebLM server. Feature licenses can be allocated from the enterprise license file to multiple AE Services servers, where they are acquired by the local WebLM server. If any of the feature licenses from the enterprise license file are not allocated to the individual AE Services servers, then these feature licenses can also float among the AE Services server. For AE Services 5.2, the use of floating licenses is not recommended. Adjust your WebLM configuration as appropriate if you are using floating licenses. 2. Log into the Application Enablement Services Management Console and select "Licensing | WebLM Server Access" to access the WebLM Logon screen. (The WebLM Logon screen should be displayed in a new browser window.)

Release 5.2 October 2010

19

3. Log into WebLM and select "Application_Enablement" to display the AE Services licensed features. 4. Note the number of TSAPI Simultaneous Users (VALUE_TSAPI_USERS) that are licensed. 5. Log into your AE Services server with root permissions and enter the following command to open the TSAPI Service Parameter Settings utility: /opt/mvap/bin/tsapiparam.sh The following screen will be displayed:

6. Use the up and down arrow keys to navigate to the "Reserved TSAPI Basic User Licenses" field, and enter the value that you recorded in Step 4 above. For example:

Release 5.2 October 2010

20

7. Use the tab key to highlight "OK" and press the Enter key. The following screen will be displayed:

8. Press the Enter key again to acknowledge that you have read this message and return to the main screen.

Release 5.2 October 2010

21

9. Use the tab key to highlight "Exit" and press the Enter key to exit the TSAPI Service Parameter Settings utility. 10. Log back into the AE Services Management Console and select "Maintenance | Service Controller". 11. Set the check box for "TSAPI Service" and click on the "Restart Service" button. When the confirmation screen is displayed, click on the "Restart" button.

Sametime Upgrade from 8.0 to 8.02 Loses the Telephony Service Provider Policy Setting
When Sametime is upgraded from 8.0.0 to 8.0.2, the telephony service provider is not enabled as a default. Re-enable the Telephony Service Provider field in the Sametime Policy. The IBM SPR is SLEE7NKJRJ.

Sametime Connect 8.0.2 Calls Cannot Be Made to the Client when Display Incoming Invitation Is Unchecked
When a Sametime client unchecks "Preferences | Notifications |Telephony notifications | Display incoming invitation" in Sametime Connect 8.0.2, Sametime calls cannot be made to that particular client. IBM has provided Hotfix # DAMD-7NJKJA.

SIP Issues

When using 3rd party call control to make a call on a SIP endpoint to a VDN that has a vector step to collect digits after an announcement, the announcement will not be played and the digits entered will not be forwarded. When using 3rd party call control to make a direct agent call to a busy agent on a SIP endpoint, the call drops. The workaround is to place the call manually. When using 3rd party call control to make a call using a TAC, the call will fail on a SIP phone if the Communication Manager does not have a TN2602AP board.

When using 3rd party call control to answer and place a call on hold on a SIP endpoint any attempt to make another call from that SIP endpoint will fail. If Communication Manager does not have a TN2602AP board, the media encryption on the SIP endpoint should be disabled. The SIP endpoint Release 5.2 October 2010

22

transport type must be set to TCP or UDP. If transport type is set to TLS, the 3rd party call control application may fail during transfer and conference. The Single Step Transfer service does not work reliably for SIP stations. DTMF Tones are not supported on SIP endpoints. User classified call does not generate an ALERTING event over an ASAI domain control association. Going off-hook on a SIP station followed by on-hook does not generate an INITIATED event. Using Third party Call control when a call is made from a SIP station, the INITIATED event is slightly delayed as compared to other station types. Subsequent events are not delayed. ACD calls that are delivered to SIP endpoints are generating Alerting Event reports that do NOT contain the split/skill extension from the associated call.

TSAPI Spy Report Sharing Violation Error

When reconfiguring the Log to File option of the TSAPI Spy application, the following error message may be displayed: The trace file could not be created: A sharing violation occurred while accessing <trace-file-name>. To circumvent this error condition, use the following procedure to change the Log to File settings while this feature is active: 1. From the TSAPI Spy, select "Options | Log to File". 2. Clear the check box for "Log Trace Messages" and click on "OK". (This will temporarily disable the Log to File feature.) 3. Select "Options | Log to File" again. 4. Update the Log to File settings as desired and click "OK".

WebLM Enterprise Model Using HTTPS

Run this workaround if all three of the following conditions are true: 1. The master WebLM Server, which hosts the Enterprise License File (ELF), is not co-located with an AE Services Server, 2. Local WebLM servers are co-located with AE Services 3. HTTPS is in use for communication between the master and local WebLM Servers [for example, to push an Allocation License File (ALF) to a local WebLM server on AE Services].

Release 5.2 October 2010

23

Locate the Enterprise Web Licensing WebLM Patch. The name of the file is ImportCertToWebLM.zip in the patch directory on the Bundled ISO and in the root directory of the SW-Only ISO. The Enterprise licensing model is not supported for the AE Services on System Platform Server offer. 1. Download importCertToWebLm.zip files to your EWL server. 2. Unzip the file 3. Follow the directions in the README to install

WebLM Session May Hang

Performing one of the following actions on WebLM may hang the session. 1. Repeatedly uninstall and install licenses 2. Repeatedly refreshing license page The current session should be closed and a new session opened.

Release 5.2 October 2010

24

RESOLVED ISSUES IN AE SERVICES RELEASE 5.2

CVLAN Service:
Prior to AE Services 5.2, in some scenarios the following informational messages were written to the error log during the initialization of the CVLAN server: ERROR:FYI:CVLAN:Cannot access certificate file, %s:/opt/coreservices/avaya/certs/pfxs/aeservicesServerCert.pem ERROR:FYI:CVLAN:Cannot access certificate file, %s:/opt/coreservices/avaya/certs/pfxs/serverServerCert.pem The content and format of these messages has been fixed.

JTAPI Client/SDK:
Prior to AE Services 4.2.2, in some scenarios the JTAPI middleware would throw a java.util.ConcurrentModificationException while processing a removeCallObserver() request and, as a result, would shutdown the Provider. Prior to AE Services 4.2.2, in some call transfer scenarios, the JTAPI middleware did not send a Call Invalid Event to a Call Observer. Prior to AE Services 5.2, a race condition existed in the JTAPI middleware such that a CallObserver could stop monitoring a device on the call before it should have.

Services:
When using SSL to communicate with a WebLM license server on the local host, the default port number is now 8443 instead of 443. In upgrade scenarios, the port number will be changed from 443 to 8443 on installations with the Bundled solution, but not for Software-Only solution.

SMS:
Prior to AE Services 5.2, the change station feature did not work as expected.

Transport:
Prior to AE Services 5.2, in some scenarios the session ID provided in an avAesAesConnLinkDown SNMP notification may have been incorrectly reported as 0.

Release 5.2 October 2010

25

TSAPI Client/SDK:
Prior to AE Services 5.2, if two different threads of a TSAPI application invoked acsOpenStream() at the same time, the TSAPI client library could cause the application to crash. Prior to AE Services 5.2, in some scenarios, if a Linux TSAPI application invoked acsFlushEventQueue() on a stream, the stream would be closed. The "Log to File" feature of the Windows TSAPI Spy application and the CSTATRACE mechanism for the Linux TSAPI client library have been enhanced to allow the user to control the amount of disk space that is used for trace files. Prior to AE Services 5.2, when uninstalling the TSAPI Linux Client RPM, the directory /opt/mvap/tsapi/client/certs was not removed. The ATTDeviceType_t enum data type that is included in the TSAPI ATT Query Device Name confirmation event has been expanded to include a new value, attDtUnknown = 0. Prior to AE Services 4.2.2, the TSAPI Exerciser included with the Windows TSAPI SDK did not provide mnemonic strings for the following cause values: EC_ALERT_TIME_EXPIRED EC_DEST_OUT_OF_ORDER EC_NOT_SUPPORTED_BY_BEARER_SERVICE EC_INCOMPATIBLE_BEARER_SERVICE EC_NETWORK_SIGNAL Prior to AE Services 5.2, in some scenarios the TSAPI client library could access uninitialized data. The following new functions have been added to the TSAPI client library: const char *acsErrorString(ACSUniversalFailure_t error); Returns a character string corresponding to the specified ACS Universal Failure error. const char *cstaErrorString(CSTAUniversalFailure_t error); Returns a character string corresponding to the specified CSTA Universal Failure error. const char *acsReturnCodeString(RetCode_t rc);

Release 5.2 October 2010

26

Returns a (terse) character string corresponding to the specified ACS return code. const char *acsReturnCodeVerboseString(RetCode_t rc); Returns a verbose character string corresponding to the specified ACS return code. If a TSAPI application invokes either acsGetEventBlock() or acsGetEventPoll(), and the value of the eventBufSize parameter indicates that the application-supplied buffer is not large enough to hold the event, then acsGetEventBlock() or acsGetEventPoll() will return ACSERR_UBUFSMALL and is expected to reset the value of the eventSizeBuf parameter to the required buffer size. Prior to AE Services 5.2, in this scenario the TSAPI client library did not reset the value of the eventSizeBuf parameter to the correct value. The Windows TSAPI Spy application and the CSTATRACE mechanism for the Linux TSAPI client library have been enhanced to include milliseconds in each time stamp. Prior to AE Services 5.2, after selecting "Start | Programs | Avaya AE Services | SDKs | TSAPI | Read Me", the Read Me file for the Windows TSAPI SDK was not displayed properly.

TSAPI Server:
The performance of the TSAPI Service has been improved when a large number of TSAPI user licenses are released in response to an acsCloseStream() or acsAbortStream() request. The CSTA message tracing feature for the TSAPI Service has been enhanced to provide decoded private data. Prior to AE Services 5.2, in some conference scenarios, a TSAPI CSTA Snapshot Device Confirmation event would include a party that had dropped off of the conference. Prior to AE Services 5.2, in some transfer scenarios, a TSAPI CSTA Established event would contain event cause EC_NEW_CALL instead of EC_TRANSFER. Prior to AE Services 4.2.2, in some scenarios the TSAPI Service would create a core file during shutdown.

Release 5.2 October 2010

27

Prior to AE Services 5.2, if a TSAPI application aborted a stream while there were outstanding TSAPI requests, the TSAPI Service would log a critical error. For AE Services 5.2, a warning message is logged with additional information. The TSAPI Service has been enhanced to log many of its parameter settings in the error log during its initialization. The TSAPI Service has been enhanced to report client connections and disconnections in the security log. The TSAPI parameter shell script (tsapiparam.sh) has been enhanced to allow the following TSAPI parameter values to be set: - The TCP Send Wait Time - The number of TCP Send Retries - The number of Reserved Unified Desktop Licenses - Whether the Persistent AAOs feature is enabled - The Persistent AAO Audit Interval - The Persistent AAO Maximum Age This shell script no longer supports setting the number of Reserved TSAPI Tier 1, Tier 2, or Tier 3 User Licenses.

Within the TSAPI Service, the default value for the TCP Send Retry Timer has been increased from 100 ms to 300 ms. The CSTA message tracing feature for the TSAPI Service has been enhanced to provide the specific Tlink name used to open the stream for TSAPI CTI links whose Security setting is "Both" [encrypted and unencrypted]. The TSAPI Service has been enhanced to expose the following data elements through SNMP: - General attributes of the TSAPI Service - Attributes of registered Tlinks - Attributes of active client connections - Attributes of the 50 most recently closed client connections

Within the TSAPI Service, the algorithm for allocating invoke IDs has been changed. Prior to AE Services 5.2, a duplicate key database insertion error would sometimes occur when processing a "User Status" request from the TSAPI Service Details OAM page. Release 5.2 October 2010

28

Prior to AE Services 5.2, the TSAPI Service could crash when attempting to open more than 2500 streams simultaneously. Prior to AE Services 4.2.2, the TSAPI Service did not always take the appropriate action if an error occurred while sending a message to a client. Within the TSAPI Service, an audit occurs at regular intervals. If this audit determines that there is a problem processing requests for one of the TSAPI CTI links, it will reject any outstanding requests for that CTI link. Prior to AE Services 4.2.2, the TSAPI Service would reject these outstanding requests with CSTA Universal Failure error RESOURCE OUT OF SERVICE. Now the TSAPI Service rejects these outstanding requests with CSTA Universal Failure error RESOURCE LIMITATION REJECTION.

Prior to AE Services 4.2.2, in some scenarios the TSAPI Service could crash when releasing a license. Beginning with AE Services 4.2.2, the TSAPI Service uses a new mechanism to control how its threads are scheduled to run. For AE Services 4.2.2, the TSAPI Service was enhanced to allow a pool of TSAPI user licenses to be reserved during startup. Reserving user licenses at startup can significantly improve the performance of the TSAPI Service in some customer environments. Beginning with AE Services 5.2, the TSAPI Service also allows a pool of Unified Desktop user licenses to be reserved during startup. Reserving Unified Desktop user licenses at startup can significantly improve the performance of the DMCC Service in some customer environments.

Prior to AE Services 5.2, the TSAPI Service did not reliably provide System Status events to applications that had invoked cstaSysStatStart(). Prior to AE Services 4.2.2, in some conference and transfer scenarios involving bridged appearances, the TSAPI Service Snapshot Call service reported the incorrect Device ID Type for some stations on the call. Beginning with AE Services 5.2, the TSAPI Service no longer generates the following WARNING message: o Undocumented ASAI cause (3,40) for C_3PSDS_CONF(54)

Release 5.2 October 2010

29

Prior to AE Services 5.2, in some scenarios the TSAPI Service would report the wrong device ID type in the Device History associated with a CSTA Connection Cleared event. Prior to AE Services 4.2.2, when message tracing was enabled for the TSAPI Service, the ATT Set Agent State confirmation event was not properly output in the trace file. The TSAPI Service has been enhanced to make fewer requests for ASAI domain control associations. Prior to AE Services 4.2.2, the Universal Call ID (UCID) provided in the CSTA Delivered event resulting from a Single Step Transfer service request was incorrect. Prior to AE Services 4.2.2, the TSAPI Service did not always provide the correct Universal Call ID (UCID) in TSAPI events after a call had been conferenced or transferred. Prior to AE Services 4.2.2, in some call scenarios the TSAPI Service would incorrectly report the local connection state of alerting bridged appearances as CS_NULL (bridged) instead of CS_ALERTING (alerting). Prior to AE Services 4.2.2, in some transfer and conference call scenarios, the TSAPI Service did not correctly indicate the existance of some bridged parties on the call. Prior to AE Services 5.2, the TSAPI Service did not reliably replicate TSAPI events that contain pointer values. Prior to AE Services 4.2.2, if far-end redirection occurs on a SIP trunk, in some scenarios the TSAPI CSTA Delivered Events for the call would contain the wrong called device. Prior to AE Services 5.2, when a TSAPI CTI link is using ASAI version 5, the TSAPI Service did not always provide the correct trunk ID in private data. Prior to AE Services 4.2.2, if the Persistent ASAI Association Objects (AAOs) feature of the TSAPI Service is enabled, under some circumstances the TSAPI Service would log warning messages indicating that asai_send() had failed. Prior to AE Services 4.2.2, in some scenarios the TSAPI Snapshot Call service would indicate that the local connection state of a party on the call Release 5.2 October 2010

30

was CS_NONE when it should have indicated that its connection state was CS_CONNECTED. Prior to AE Services 4.2.2, in some single-step transfer call scenarios involving stations with bridged appearances, the TSAPI Service would provide the wrong calling device in TSAPI events. Note that the single-step transfer call service is used by Microsoft Office Communicator. Prior to AE Services 5.2, if a call is transferred multiple times using the single-step transfer call service, in some scenarios the TSAPI Service would provide the wrong calling device in TSAPI events. Note that the single-step transfer call service is used by Microsoft Office Communicator. Prior to AE Services 4.2.2, the TSAPI Service would indicate that the reason for Original Call Information in an event was OR_NEW_CALL when there was no Original Call Information in the event. Now the TSAPI Service indicates reason OR_NONE when there is no Original Call Information in an event. Beginning with AE Services 4.2.2, the CRITICAL error message "cannot get memory from msg heap" has been changed to a WARNING error message, and the format of the message has been changed to: "there is not enough space available in the message buffer for event <event-classname>(<event-class>) <event-type-name>(<event-type>)." Prior to AE Services 5.2, in some scenarios the TSAPI Service would incorrectly provide device ID type EXPLICIT PRIVATE LOCAL NUMBER for a device on the public network. For AE Services 5.2, the device ID types provided by the TSAPI Service are more closely aligned with the address type and numbering plan information provided by ASAI. Prior to AE Services 4.2.2, in some predictive call scenarios the TSAPI Snapshot Call service would not return all of the parties on the call. Within the TSAPI Service, a new thread status has been added, making it possible to detect when the TSAPI Service is waiting for a WebLM operation to complete. Prior to AE Services 4.2.2, in some scenarios involving stations with bridged appearances, it was only possible to perform a single single-step transfer operation; subsequent single-step transfer operations would fail.

Release 5.2 October 2010

31

Note that the single-step transfer call service is used by Microsoft Office Communicator. Prior to AE Services 5.2, in some scenarios involving Redirection On No Answer (RONA), the TSAPI Service would not provide a CSTA Queued event to applications. Prior to AE Services 5.2, when there are multiple AE Servers monitoring the same station device, in some transfer scenarios the TSAPI service would not relinquish the ASAI station domain control for the device quickly enough, causing subsequent call control requests on that device to fail with CSTA error 44 (Outstanding Request Limit Exceeded). Prior to AE Services 4.2.2, when message tracing is enabled for the TSAPI Service, it was possible for the TSAPI Service to crash when tracing the confirmation message for an extension status value query. Prior to AE Services 5.2, in some predictive call scenarios the TSAPI Service did not provide a device ID for the dropped connection in a CSTA Connection Cleared event. Prior to AE Services 5.2, in some predictive call scenarios a snapshot of the call would not include the called device Prior to AE Services 4.2.2, the CSTA Conferenced events resulting from a single-step conference operation that included a predictive call did not always contain all of the connections on the call. Beginning with AE Services 4.2.2, the TSAPI Service no longer generates the following WARNING messages: o Undocumented ASAI cause (0,29) for C_DENIAL(6). o Undocumented ASAI cause (0,29) for C_DROP(4) o Undocumented ASAI cause (0,41) for C_VQ_CONF(33) The format of error messages generated by the TSAPI PBX driver has been simplified. Beginning with AE Services 4.2.2, when message tracing is enabled for the TSAPI Service, the TSAPI Service includes the private data associated with an ACS Open Stream or ACS Open Stream Confirmation event in the trace output. Within the TSAPI Service, the algorithm for allocating session IDs has been changed.

Release 5.2 October 2010

32

Prior to AE Services 5.2, the TSAPI Service did not always take the appropriate action if an error occurred while receiving a message from a client.

Release 5.2 October 2010

33