No, AE Services supports Device Media and Call Control (DMCC), Telephony Service API (TSAPI), Java Telephony API (JTAPI) and Web services (Telephony and System Management Service (SMS) Web services)

Only DMCC has a .NET API.

TSAPI is a C++ API for Computer Telephony Interface (CTI) and is supported on UNIX and Windows platforms. Most TSAPI functionality can be accessed through the AE Services Release 6.1 and higher DMCC APIs.

JTAPI is a platform independent Java-based API to do CTI. It gives almost same functionality of TSAPI and it is a Java implementation of TSAPI driver using the JTAPI object model.

Using the Telephone Web service, an application can do basic CTI functionality like make call, conference all, transfer call, drop call, etc. It is intended for simple click to call functionality.

With SMS, one can do provisioning of the Communication Manager - like configuring stations, creating stations, etc. It provides a SOAP interface, and thus is language independent. Sample applications in Java are available.

Each release of AE Services has historically required newer versions of Red Hat Enterprise Linux. The required release of Red Hat Enterprise Linux is specified in the Software Only Installation documentation for the AE Services release in question. The installation documentation can be found on the DevConnect portal and Avaya Customer Service portal (www.avaya.com/support) associated with the product and release. For example for AE Services release 6.2 the appropriate documentation is located here: and is titled "Implementing Avaya Aura Application Enablement Services 6.2 in a Software-only Environment"

A no-cost DevConnect Remote Lab is available that enables application developers to access an Avaya Aura Communication Manager and AE Services configuration via a VPN connection. You can reserve a Remote Lab session via the DevConnect portal at https://devconnect.avaya.com. Once logged in, select the Remote Labs link in the left-hand menu, and then choose the Avaya Aura AE Services & Communication Manager from the DevConnect Remote Labs Index.

There are also number of procurement options that may be useful:

• Avaya Aura Basic Development Environment (all members)
• Midsized Enterprise Solution (Enhanced-level members only)

To learn more about these options, access the DevConnect portal and select Procurement from the left panel menu. Once you have reviewed the limitations on procurements, select the link titled Access DevConnect Procurement Benefits.

The configuration procedure is as follows:

1. In Avaya Aura Communication Manager: in the softphone extension's station form page 2, set Auto Answer to 'all' or 'acd' (to only auto answer ACD calls) and on page 4 or later configure a Release button.
2. In the Avaya IP Softphone application, go to Tools->Program Options and verify that 'Use headset mode' is checked.
3. Register the softphone (i.e. provide the extension and security code), take it off-hook, and then press the Release button to enter an off-hook idle state.
4. Place a call to the station and verify that the call is auto-answered.

Note that the DMCC SDK does not support auto-answer configurations. Many cases work, but some cause issues. Support from DMCC for auto answer has improved release over release as problematic scenarios are found, and fixed, although the official stance is one of non-support.

In AE Services there is a limit of 16 CTI (Computer Telephony Integration) links from AE Services to one or more Communication Managers. Each service (DLG, CVLAN, and TSAPI) consumes one or more CTI links. Between an AE Services and Communication Manager you provision a 'Switch Connection'. You provision DLG, CVLAN, and TSAPI CTI links to use a specific Switch Connection. Each DLG, CVLAN or TSAPI CTI link you provision is counted against the limit of 16 supported by that AE Services server. DMCC DAPI links (used for licensing and call information services) and SMS connections are not counted against the limit. H.323 DMCC Device registrations are not counted against the limit.

Communication Manager 3.0 supported up to 16 CTI Links. Communication Manager 3.1 and more recent releases supports up to 64 CTI links. If you are using CTI link types, you can create 16 CTI links to a 3.0 Communication Manager and 64 CTI links to more recent Communication Manager releases from one or more AE Services servers.

Yes, both the CVLAN and DLG applications can be run simultaneously on the same MAP-D. This configuration continues to be supported in CM 2.x and 3.0 for existing MAP-D customers.

Yes, you do need the ASAI Link Core Capabilities customer option enabled for Single Step Conference, and this information is documented in the "Administrator Guide for Avaya Communication Manager" document 03-300509, Issue 3, dated Feb 2007 (http://support.avaya.com/elmodocs2/comm_mgr/r4_0/pdfs/03_300509_3.pdf)

Yes, the ASAI core software option in the "display system-parameters customer-options" SAT form will need to be enabled on Communication Manager for integration with AE Services.

The maximum number of bridged line appearances supported on a specific release of Communication Manager is documented in "Avaya Communication Manager System Capacities Table".

AE Services provides limited support for interactions with Bridging. It is recommended that application developers review the information that is in the TSAPI for Communication Manager Programmer's Reference related to Bridging. It applies to TSAPI, JTAPI and DMCC Call Control applications. CVLAN and DLG application developers should refer to the ASAI Programmer's Reference where similar information is provided. The document states what is supported. You should assume that everything else is not supported.

You can Service Observe an Avaya Softconsole, but an Avaya Softconsole cannot Service Observe another station. In other words, an Avaya Softconsole can be service observed, but cannot be a service observer.

You can Single Step Conference a phone onto a call that an Avaya Softconsole is participating in, but an Avaya Softconsole cannot be Single Step Conferenced into a call. You cannot use TSAPI to monitor call information from an Attendant console (soft or hard). Thus unless you can access the call identifier by some other mechanism (monitoring the other party in the call), recording an attendant by this technique is not achievable.

There isn't a way to emulate a 'hard hold' on the analog phone, as the 'hard hold' typically requires a physical button. One way you could accomplish the hold feature is by using the switch-hook flash to activate a 'soft hold' as the first step, and then press switch-hook flash again to get back to the held call. A switch-hook flash is typically a 500 ms on hook interval +/- 100 ms followed by going back off hook. However this interval varies by country and is configurable on Communication Manager. CTI can also be used to place a call on hold at an analog station. Once a call is held at an analog station, if the station is placed in an on-hook state, the station will alert to remind the user of the held call. Going off hook reconnects the call to the user. To prevent this re-alert, the phone must be left in an off hook state.

Yes. This can be accomplished with the VDN of Origin Announcement, which allows a short message to be played to the agent prior to connecting to the incoming call. For more information, please refer to 'Avaya Call Center Release 4.0 Automatic Call Distribution (ACD) Guide' document 07-600779 Release 4.0 dated Feb 2007 (http://support.avaya.com/elmodocs2/callctr/r4_0/ACD_CallCenter.pdf)

The same trunk information is provided, just as is the case with PRI.

Currently it is not possible to enable 'list announcements' with setting 'Administrator Features' to 'n'.

The community string can be changed via the SNMP Set command and you can also customize your community string with system values SNMPADD and SNMPSTRING.

When the 'Event Minimization' feature is set to 'y' on a CTI link, then only one set of events for a call is sent to the CTI link, even if more than one device in the call are being monitored through that link.

If two stations (example, A1 and A2 which are bridged together) and a VDN are being monitored, when the VDN delivers the call to A1 (and thus to A2) normally three delivered events are sent by Communication Manager. If Event Minimization is set to 'y', the number of events can be reduced to one on the link.

Note: TSAPI links should always have 'Event Minimization' sent to 'n' for proper operation.

Complete the following configuration to enable the 'Event Minimization' feature.

• Use the 'change cti-link [cti-link number]' command and go to Page 2 of the command.
• Set the 'Event Minimization' feature to 'y' and save. For more information, see the version of Administrator Guide for Avaya Communication Manager appropriate for the release of Communication Manager you are working with.

These changes will take effect the next time the ASAI CTI link is activated after restarting the AE Services server.

No. All third party call control mechanisms rely on the underlying ASAI functionality. All have a license cost. The least expensive way to acquire access to third party call control functionality is via TSAPI.

Any call that utilizes a trunk as a result of 'MakePredictiveCall', will need to utilize services in Communication Manager that automatically select the actual trunk being accessed. These services are typically Automatic Route Selection (ARS) (commonly dial 9), Automatic Alternate Routing (AAR - used in private network situations), or Uniform Dial Plan (UDP) which leverages one of the above two services. The destination number typically includes the ARS or AAR access code. When UDP is used the routing tables specify an ARS or AAR route explicitly.

It is not possible to find out the number of RTP packets going in and out of an IP phone using JTAPI or DMCC. The way to accomplish this is through Real-time Control Protocol (RTCP) Monitoring. Configure the IP address of the server that will receive RTCP information from Avaya Communication Manager using the SAT command 'change ip-network-region'.

The limitation is within Communication Manager and provides a maximum of four domain controls per station up through release 6.3, and was increased to eight with release 7.0. Please note that this is a CM limitation and not the AE Services limitation. Depending in which API is used, one or more of these domain controls is used for a station monitor (domain control on a station extension). With DLG and CVLAN each application consumes one domain control. With TSAPI, JTAPI and DMCC, a single domain control is used by all applications monitoring that station extension (they are multiplexed).

If multiple AE Services servers are involved, each AE Services server acts independently from Communication Manager's perspective. So for example, two TSAPI applications using one AE Services server consume one domain control on Communication Manager for a specific station extension, while if the same two applications are using separate AE Services servers to monitor the same extension, two Communication Manager domain controls would be consumed for that station.

Yes, TSAPI API or JTAPI API can be used to access this information. The TSAPI API method is attQueryACDSplit(), and the JTAPI API method is ACDAddress.getNumberQueued(). Starting with AE Services release 6.0 most TSAPI capabilities are exposed in the DMCC SDK. The DMCC method GetAcdSplit() will return the number of agents logged in, the number of available agents and the number of calls in the split's queue.

Assuming that you purchase IP Softphone licenses (IP_API_A) for Communication Manager , AE Services will allow applications connecting to it to access the following capabilities:

1. DMCC services except for:
   1. Call Control Services (requires a TSAPI license)
   2. Call Information Services (requires Applications Enablement Protocol (AEP) transport link license)
   3. Secure access to DMCC services (i.e. port 4722)
2. System Management Service (Note that AE Services 4.1 requires a System Management Service (SMS) license. Prior AE Services versions (3.x) did not, and starting with release 5.1 AE Services does not require a SMS license).
3. User Management Service (Note that AE Services and later no longer support the User Management Service).

AE Services will operation in a 30 day trial license mode for all services starting with release 5.1 regardless of their licensed state on the server. Once the trial period has expired, subsequent attempts to acquire licenses will be blocked until the server is properly licensed for its capacity usage.

Typically an application that wants to record calls at a station, will use the DMCC API and will implement one IP soft phone per recording device.

There are three forms of call recording supported through the AE Services APIs and multiple techniques for implementing them.

• Service Observing
• Single Step Conference
• Multiple Registrations Per Device

With Service Observing (SO), the DMCC soft phone has a service observing (SO) button provisioned on it. As the application initializes, it activates service observing on a specific destination station (the observed extension or observee). When calls arrive at the observed extension, Communication Manager automatically connects the SO party into the call when the destination station answers. Release 4.0 increases the number of SO parties in a call to two. Typically TSAPI is used to monitor the observed extension to collect call data such as calling party number.

Alternatively, the application uses 4.1 DMCC, or any release of TSAPI or JTAPI to monitor an extension for incoming calls and/or a specific button push which indicates that the user wishes to record the call. The application then invokes the DMCC, TSAPI or JTAPI Single Step Conference feature to conference in the recording device when the recorded station is active on a call. The recording device is implemented as a DMCC Softphone.

With Multiple Registrations per Device, the DMCC softphone is registered to the same extension as the recorded device and gets a copy of the RTP stream for the device (which includes the RTP from the recorded device summed in). This technique overcomes some of the limitations of the other techniques.

Either form of recording can take advantage of 'silent' mode for the party that was added into the call. With silent recording, the participants of the call are unaware that a recording resource was added to the call. See the appropriate API documentation to learn how to utilize this capability.

Call recording of EC500 stations and SIP telephones was added in release 6.2 of AE Services and Communication Manager.

Please review the following document for detailed information on these techniques.

DevConnect Developer Guide: Developing Client-side Call Recording Applications using Avaya Application Enablement Services (899 KB .pdf)

Applications using Device and Media control typically require registration of the devices that are used in the application. Up through release 4.2 of AE Services Registration of a device associated with the Device, Media and Call Control API requires an 'IP_API_A' license. Starting in AE Services release 4.2 in conjunction with Communication Manager release 5.1, two licensing mechanisms are supported. IP_API_A on Communication Manager and DMCC_DMC on the WebLM license manager associated with AE Services.

The number of 'IP_API_A' licenses can be obtained by executing the Communication Manager SAT command 'display system-parameters customer-options' and then navigating to the page just before the last page of the form. The maximum number of 'IP_API_A' licenses is listed under the 'Limit' column and the number of licenses currently allocated is displayed under the 'Used' column. One 'IP_API_A' license is used for each DMCC station. If there is no IP_API_A row, then zero licenses are configured. Note that IP_API_A licenses are also used for IP Softphones, which is one reason that DMCC_DMC licenses were adopted in AE Services release 4.2.

For additional information related to licensing, see the AE Services licensing section of the Avaya Aura? Application Enablement Services Overview document for the release of AE Services you are working with.

In the System Access Terminal (SAT) of Communication Manager, execute the 'status aesvcs interface' command to see the status of the AESVCS connection interfaces that Communication Manager is listening for. The state of an interface can be one of the following:

Disabled - The interface is disabled.

Intfce-down - The interface is not functioning and cannot accept incoming communications.

Listening - The interface is up and running and AESVCS services has connected to it.

For more information, see "Maintenance Commands for Avaya, Communication Manager ".

Alternatively, you can access the Web OA&M interface for AE Services, and navigate through Status (where you can see the running status of each of the different API middleware services), and then to Status and Control-> Switch Connection Summary where you can see a table displaying the connectivity status with each of the switch connections that has been provisioned in AE Services. The switch connection is the transport connction between AE Services and a particular Communication Manager. The Connection State can be in the following states:

Talking - normal in-service operational state

TCP Up - transitional state indicating a socket connection has been established and there is handshake negotiation occurring

TCP Down - A state indicating a socket connection was created and has come down for a variety of reasons

Idle - An indication that the connection is not talking, and something is preventing it from entering the TCP states

Invalid client - An indication of a provisioning error

Offline - the switch connection has manually been taken 'offline' through a provisioning/control interface.

Additional information about the state of sessions within a service is available by navigating through Status -> Status and Control -> "XXXX" Service Summary.

Up to sixteen CMs can be configured on one AE Services server without failover capacity and up to 8 CMs can be configured with failover capacity. The total number of CMs that can be configured on one AE Services server is limited by the number Application Enablement protocol (AEP) licenses. For further information refer 'Application Enablement Protocol connections licensing' section in document 'Avaya MultiVantage Application Enablement Services Overview 02-300360 Release 4.1 December 2007 Issue 4' The number of AEP licenses can be found on the following page: Web License Manager > Application_Enablement.

Visit AE Services server O&M page: Administration > CTI Link Admin > TSAPI Links > Add Link. The 'Link' option displays the maximum number of CMs that can be configured on an AE Services server (which shows 16). If sufficient AEP licenses are not available, 'Conn State' on 'Switch Connection Summary' page shows 'No license available' (This page can be found at location CTI OAM Home > Status and Control > Switch Conn Summary').

In an AE Services server, the log files for installation or upgrade are in the directory: '/var/disk/logs/cinstall-yyyy-mmdd-tttt', where 'yyyy-mmdd-tttt' is a date and time stamp. Example of a log file name: 'cinstall-2007-0309-0951'.

An AE Services server keeps copies of the RPM packages that are installed on it (the last three installed packages). The RPMs are stored on an AE Services server in the directory: '/var/disk/software/'.

In release 4.1 AES you can not use a '$' (dollar sign) in a password for anything other than the last character. The check on the web page does not verify this condition in the 4.1 release.

No, it is not possible to list all the calls and all the ongoing sessions on a Communication Manager using any AE Services SDK. But Monitoring Services and Snapshot Services can obtain third party information about the devices participating in a specific call or the information about calls associated with a given device. Monitoring services can monitor devices like ACD splits, VDNs and station extensions. Snapshot services can retrieve information from station extensions.

The Device, Media, and Call Control (DMCC) SDK has better support for handling media and is more apt for developing media centric applications. DMCC SDK is supported on Java, XML and .NET platforms and can be downloaded from the Avaya DevConnect website (www.avaya.com/devconnect).

To change the password requirements of all AE Services users (including CTI), please follow these steps:

1. Log in to AE Services OAM page.
2. Select Security Administration.
3. Select PAM (Pluggable Authentication Module) Management.
4. Select PAM Module Config.

Modify the form as per the requirements.

The password requirements for all AE Services users are controlled by the same settings. Thus changing these settings will also impact administration users of AE Services.

AE Services supports the 13 digit dial plan for all services except DLG (DMCC, TSAPI, JTAPI, and CVLAN for IC). This feature will be supported on AE Services 4.1 and CM 5.0 or later.

A common question among AE Services developers is acquisition of a list of stations' extensions, and their associated IP and MAC addresses. The AE Services SMS interface can help provide some of this information (extension/IP) for registered stations using the 'list registered-ip-stations' command. The interest level is high enough to justify a FAQ in this area describing how to acquire that information from Communication Manager. There is a corresponding FAQ in the IP stations FAQ list titled 'How can SNMP be enabled on the 46xx series IP telephones?' that details how to acquire the MAC information by sending a query to the 46xx series IP Stations.

Follow the steps mentioned below to configure SNMP in the Avaya S8700/S8300 servers and then run the SNMP command provided below:

1. Log in to Avaya Communication Manager (https://< Avaya Server IP address >).
2. Provide appropriate credentials to access the system.
3. Select the Launch Maintenance Web Interface link.
4. Select Agent Status under the Alarm section in the left pane. Stop the Master Agent by clicking the Stop Agent button.
5. Select SNMP Agents under the Alarm section in the left pane as described below:
   1. Select any IP address for the IP Addresses for the SNMP Access field.
   2. Check the Enable SNMP Version 1 box, and provide Community String for the Community Name (read-only) field. The default community string for read-only is public. Provide Community String for the Community Name (read-write) field. The default community string for read-write is private. Note: Make sure to change read-write community string from private to something else.
   3. Repeat the previous step for the Enable SNMP Version 2c field.
   4. Click the Submit button.
6. Select Firewall under the Alarm section as below:
   1. Check both SNMP check boxes.
   2. Click the Submit button.
7. Select Agent Status under the Alarm section. Start the Master Agent by clicking the Start Agent button.

Following are the three commands used to acquire the Registered IP stations' IP address/Extensions/MAC address using SNMP. Note that these commands were run on Communication Manager (localhost); replace that string with the IP address of Communication Manager when running these commands from another server:

1. To list the IP addresses of the registered stations on Communication Manager, run the command: "snmpwalk -Os -v 1 -c public localhost 1.3.6.1.4.1.6889.2.8.1.12.1.1.18 | grep "50\.48\.48" | grep STRING" where localhost is the Avaya server IP address.
2. To get the extension number of the IP address of the registered phone: snmpwalk -Os -v 1 -c public < IP address of the phone > 1.3.6.1.4.1.6889.2.69.1.4.9.0
3. To get the MAC address of the IP address of the registered phone: snmpwalk -Os -v 1 -c public < IP address of the phone > 1.3.6.1.2.1.2.2.1.6

Check the connection state on the AE Services OAM page.

1. Open a web browser
2. Type in the URL - 'https://< aes_server_ip >:< port_no >/MVAP'
3. Login with proper credentials
4. Navigate to - Status and Control > Switch Conn Summary.

If the connection state is 'talking' and the Tlink is still not listed in the Administration > Security Database > Tlinks page, restart TSAPI Services and then check for the Tlink. Tlinks are service identifiers that are automatically generated by the TSAPI Service when the TSAPI service starts. If the connection state is other than 'talking', it means the CM and AE Services server are not configured correctly. Kindly refer to the Avaya MultiVantage Application Enablement Services Administration and Maintenance Guide Release 4.1 (document number 02-300357) and follow the configuration procedure (Chapter 1 and Chapter 2) again.

Check that the hostname of the AE Services server (Linux> hostname) matches the value that is provisioned in Communication Manager's 'change ip-services' System Access Terminal form in the field titled 'AE Services server' on page 3. The hostname/AE Services server is case sensitive and must match in both places.

This problem typically occurs on a software-only installation of AE Services because the installation instructions were not properly followed and Security Enhanced Linux (SELinux) is kept enabled. Run the command '/usr/sbin/sestatus' on the AE Services server. If the SELinux status is 'enforcing', change it to 'disabled'.

To change the sestatus, follow the following steps:

1. Change the directory to /etc/selinux
2. Edit the config file.
3. Change the SELINUX=enabled setting to SELINUX=disabled

Since the Communication Manager (CM) is not aware of recording, there is no way to provide a warning tone for call recording in CM. To provide call recording warning tones, the recording application itself needs to provide the warning tones through the RTP media stream.

Hot-Desking is a term used to describe an environment where a desk is used by multiple people. As the user of the phone is always changing, the available phone on the desk is first unregistered with one user and then registered with another user's extension/password. Another term for this is IP-Hoteling. In this environment the number of available phones/desks doesn't match the number of people using them. This may occur when:

1. People are working on rotating shifts (call centers), or
2. People are not always working at the same desk (temporary work centers).

In either case, users need a phone number that follows them around as they use different desks or when many users share the same desk. In other words, a specific user needs a telephone number that is unique to them, regardless of where they may be sitting. This practice is called 'Hot-Desking'.

SAT sessions are connections to the Communication Manager (CM) for administration purposes. Two types of SAT sessions are available: secure (using SSH) and non-secure (using telnet). SSH is established on TCP port 5022 and telnet is established on TCP port 5023. In CM 4.0 and above versions the telnet port is disabled by default. It has to be enabled explicitly by configuring ports on the Communication Manager server. To enable the 5023 port click "Firewall" under the "Security" heading in the maintenance Web interface of the CM and select the check box for "telnet" service for Input to Server and Output from Server.

Yes, an application can maintain a pool of secure SAT connections to access data from Communication Manager. In such a case, only one session can execute change commands at a time (e.g., change trunk-group <group number>, change station <extension number>). The maximum number of pool of connection is limited by the switch type being used.

Once the call is queued at a split/skill on a Communication Manager (CM), the call is serviced in the order it was queued on the ACD (first-in/first-out, i.e. FIFO approach). One possible way to allow an Agent to selectively answer a call is to have the application decide which call the Agent would like to service before sending it to the split/skill; the application can then mark the call as a 'Direct Agent' call for that Agent. To achieve this operation, the calls are directed to devices (extensions) that the application manages and the application answers them and puts them on hold. When the agent selects a call from the list managed by the application, the application transfers that call to that agent via a direct agent call.

The steps to add the Auto-in or Manual-in button on the phone are described below:

1. Login to the Communication Manager SAT terminal.
2. Execute the command
   1. if modifying an existing station: "change station < extension_number >"
   2. if adding a new station:"add station < extension_number >"
3. In the station form, go to page 4 and under "BUTTON ASSIGNMENTS" assign 'manual-in' or 'auto-in' to the desired feature button.
4. Submit the form and do "save translation" command to make the change permanent.

For a list of feature buttons refer to document "Administrator Guide for Avaya Communication Manager, 03-300509, Issue 3, February 2007".

If the agent logs in 'manual-in' mode then after the ACD call completion, Communication Manager puts the agent in 'after call work' mode. This prevents agent becoming available for new ACD calls. In order to accept calls again, Agent need to change the state to 'Ready' by pressing the 'manual-in' button.

A secondary server will not start monitoring an extension automatically, thus the application will not automatically start receiving events. The application will need to restart the monitors in order to begin receiving events (with AE Services 4.1 and Communication Manager 5.0, the application can have two monitors on the same extension through separate AE Servers and thus the loss of one AE Services server need not necessarily disrupt the flow of events to the application). After a failover and reestablishment of monitors, to find the state of existing or ongoing calls, the application must do a snapshot device and snapshot call. It is recommended to do both (i.e. snapshot call and snapshot device) as the call may have changed state and there may be more (or less) active calls on the device. Ideally this should be part of applications' general initialization strategy.

The features 'CTI-Station' and 'Phantom Calls' need to be enabled on CM for Phantom calls to work. On the SAT terminal execute the following command:

display system-parameters customer-options

Browse to the page where the ASAI ENHANCED FEATURES fields are displayed, and check whether the features 'CTI Station' and 'Phantom Call' are set to 'y'. If they are not, then contact your Avaya Support Team or Business Partner to have these features enabled.

It is not possible to programmatically obtain CLAN IP addresses configured on an AE Services Server. However, the IP addresses can be obtained or modified by logging in to the AE Services server's OA&M web page and browsing to

Administration -> Switch Connection.

Select the switch connection and click the Edit CLAN IP button. The CLAN IP addresses of that particular switch connection are displayed and can be modified if required.

Yes, multiple Communication Managers can be configured on an AE Services' server and the server is capable of talking to multiple Communication Managers simultaneously (The maximum possible number of CTI-links and hence the number of Communication Managers that can be configured on AE Services server, is 16. However, Avaya recommends two links per Communication Manager, thereby limiting the number of CTI-links to 8). To communicate with a specific Communication Manager, an application needs to open a stream for a specific CTI-Link on the AE Services server. This CTI-Link determines which CM is referenced. The application can use multiple CTI-links by managing various open streams.

This issue seems to crop up on Avaya Aura BDE occasionally but never on a real AE Services server. Our suspicion is it is tied to the power management settings in VMWare.

To fix it,

1. Use the AES web based OA&M and navigate to CTI OAM Administration > Administration > Switch Connection
2. Click the edit button for the cmsim switch connection.
3. Set the password to: 'devconnect123456'
4. Click update, Click OK.

Then check the power settings in VMWare (these instructions are for Workstation).

1. Click on vmware VM -> Settings (select [options] tab), select Power from the list on the left
2. Make sure that power control [red square] setting is "shutdown guest".
3. Make sure that the "reset" setting [recycling red/green arrows] is "Restart Guest".

When you shutdown Avaya Aura BDE make sure to issue the command: craft@aessim> sudo /sbin/shutdown -h to allow linux to properly shutdown.

A 'Phantom Extension' is a station that can be configured on the PBX without consuming any PBX hardware resources but consumes station licenses and can be administered without any associated hardware. Such a station can be used to support various service scenarios. One specialized use is with CTI as an origination point for calls. When a phantom station is used with CTI, the station should be provisioned as a "CTI" station type which utilizes the phantom station capabilities, but has modifications specifically for the CTI interface on Communication Manager.

Phantom extensions can be provisioned on the Communication Manager by setting the station Type to "CTI" (this automatically sets the Port to "X"). If the phantom extension is to be used for CTI calls, "CTI Station" and "Phantom Calls" features must be enabled on Communication Manager's "change system-parameters customer-options" form via a system licensing change. For more information on this, please refer to FAQ "What needs to be enabled on the Avaya Communication Manager (CM) to allow Phantom calls?" in AE Services FAQ section.

The ability to set the text for a button is not supported.

By using the IP phone's PUSH capability, where a WML page can be sent to the phone, the softkeys alongside of the WML page can be 'labeled' and when they are pressed the phone can then trigger actions based on the contents of the WML page. Those actions are sent to the WML Server and not to Communication Manager.

This functionality (WML or IP PUSH) is only present in Avaya IP phones available today and in the SIP devices which will be made available in the near future. IP PUSH support will not be available in DCP or other multifunction TDM based phones.

When most (but not all) buttons are pressed, AE Services' DMCC API provides lamp update events when the button's lamp(s) change state. There is no provision to get events on a button up or down transition from any API provided by Avaya.

Tracking keypad button presses (0-9, *, #) can only be done by monitoring for the calling/called party numbers or adding a server media mode device to the call and performing tone collection. If multiple parties are in the call, the application cannot determine which party is pressing the keypad buttons.

The Telephony Services API (TSAPI) function "Query ACD Split Service" can be used to retrieve the number of ACD agents available to receive calls through the split, the number of calls in queue, and the number of agents logged in. The number of calls in queue does not include direct-agent calls. The "Query Agent Login Service" provides the extension of each ACD agent logged into the specified ACD split.

For more information, please refer to Avaya MultiVantage Application Enablement Services TSAPI for Avaya Communication Manager Programmer's Reference, 02-300544, Release 4.2, May 2008, Issue 4, available on DevConnect portal.

For Java Telephony API (JTAPI), ACDAddress, Agent classes and associated methods provide this functionality. For more information, please refer to API documentation of "package javax.telephony.callcenter" in JTAPI javadoc version 4.2.

The heartbeat mechanism between AES transport and CM is fully symmetrical - it goes in both directions. It is on a per socket (TCP/IP CLAN) connection basis, and heartbeats are only sent on idle connections. If a heartbeat failure is detected, both CM and AES will log an error (hardware error log for CM, and /opt/mvap/logs/log.YYYYMMDD for AES). The only difference between CM and AES is the timers used. CM uses 10 seconds idle time (to send a heartbeat), 20 seconds response time (to receive a response). AES uses 20 seconds idle time, 20 seconds response time. The difference in timers is intentional, and should cause CM to be the primary sender of heartbeats, but allows AES to also detect failures (and helps prevent issues with both sides detecting failure at the same time).

Here is the heartbeat algorithm (again, implemented on CM and AES), which is used on a per socket (CLAN) basis:

1. If no messages are received (read) over a particular socket (TCP/IP) connection for the idle time period, send (write) a heartbeat request over that socket.
2. If any message is received (read) over that socket before the response time out period, the heartbeat request is satisfied, the response timer is cleared and the idle timer is reset.
3. If no messages are received over that socket before the response time out period, consider the connection down and close the socket (which will also cause an Error Notification/No Reply to Heartbeat message to be sent first - but this will likely not make it through to the other side, unless there is a "one-way" communication problem), and log an error.

Also note that both CM and AES will respond to a heartbeat request with a heartbeat reply on the socket over which it received the request regardless of the other messages being sent (note that, in general, traffic can be sent over any socket connection in the switch connection - heartbeat replies, however, must go over a particular socket). Also note that if only one side is sending messages over a particular socket (with no messages coming back), it will eventually send a heartbeat request over that socket to make sure that the other side is still alive.

Media or Voice data are exchanged between an application and a Communication Manager server using H.323 RTP packets. From the application developer's perspective however, RTP is not a part of the transport layer but a part of the application layer. This is because the developer must integrate RTP into the application. In particular, for the sender side of the application, the developer must write code into the application which creates the RTP encapsulating packets; the application then sends the RTP packets into a UDP socket interface. Similarly, at the receiver side of the application, the RTP packets enter the application through a UDP socket interface; the developer therefore must write code into the application that extracts the media chunks from the RTP packets.

Avaya provides a Java media stack implementation that Java developers can incorporate to handle a portion of this task. The Java media stack API and documentation is available on the devconnect web portal in the DMCC SDKs web page (http://www.avaya.com/devconnect).

UEC is digit sequence that may have been entered by the caller either through the call prompting feature or via the collected digits feature. Typically, a VDN collects digits from the user when a call is delivered at the VDN and passes the call to its next destination, which may either be a station or another VDN. A monitored VDN reports only the UEC that it receives and not the UEC it collects. If there are multiple VDNs in the call flow which collect the UEC, then only the last UEC is reported. Applications receive UEC as a private data member in events such as Delivered, Established, etc.

On the other hand, applications are allowed to associate User-To-User Information (UUI) with a call while initiating, diverting, routing or dropping a call. This information may be a customer number, credit card number, alphanumeric digits, or a binary string. The applications are responsible for copying or entering the information into the call's UUI. When an application enters information into a call's UUI, any previous UUI is overwritten. UUI is shared across CTI platforms, i.e., UUI is sent over ISDN, SIP and H.323 trunks to remote PBXs where it is available to CTI applications at the remote switch.

For more detailed information on UEC and UUI, please refer Avaya MultiVantage Application Enablement Services TSAPI for Avaya Communication Manager Programmer's Reference, 02-300544, Release 4.2, May 2008, Issue 4 available on http://www.avaya.com/devconnect and Avaya Call Center Release 5.0 Call Vectoring and Expert Agent Selection (EAS) Guide, 07-600780, Release 5.0, January 2008, available on www.avaya.com/support.

The commands for accessing the forms that allow configuration of these fields are as follows:

1. >Use the SAT command display system-parameters customer-options. Browse to the OPTIONAL FEATURES section and verify the field Audible Message Waiting is set to 'Y'. If it is not, contact your Business Partner or Avaya Sales personal to have it modified.
2. >Use the SAT command change station [xxxx] where xxxx is the extension number. Browse to the Station section. In Feature Options, set the field Audible Message Waiting to 'Y' and set the Message Server Name field (which has been renamed as Audix Name) to the server name.

For more information on SAT commands, please refer Administrator Guide for Avaya Communication Manager, 03-300509, Issue 4.0, Release 5.0, January 2008 available on www.avaya.com/support.

The following list provides the available methods to retrieve the information:

1. For DMCC, the other party's name and extension number can be retrieved from the DisplayUpdatedEvent method when there is only one other party in the call and the display mode is "Normal".
2. For the DMCC Java SDK, the DisplayUpdatedEvent.getContentsOfDisplay() method provides the display contents.
3. For the DMCC .NET SDK, the DisplayUpdatedEventArgs.getContentsOfDisplay() method can be used to provide the display contents.
4. For TSAPI, please refer to the "Can I obtain the caller ID names using TSAPI?" FAQ.
5. In JTAPI, to retrieve the calling party's name, i.e., the name of the extension set in Communication Manager, use the method getDirectoryName() on the LucentTerminal or the LucentAddress object.
6. Using SMS Web services, an extension's name can be retrieved by using System Manageent Service (SMS). An application can send a SOAP request and set the Model as 'Agent', Operation as 'Display' and Qualifier as xxxxx where xxxxx is the extension number of the calling party, and retrieve the name associated with the extension.

Note: With DMCC, the name associated with an extension can only be retrieved when a call is active. However, with TSAPI, JTAPI and SMS Web Services, the name associated with an extension can be retrieved when the extension is known and the user would like to retrieve the associated name.

Listed below is the procedure to enable "Agent Login" on Communication Manager:

Use the System Access Terminal (SAT) to run these commands and change the settings:

1. First check if the features necessary for the call center scenario are enabled on your system.
   • Use SAT Command "display system-parameters customer-options". Browse to 'CALL CENTER OPRTIONAL FEATURES' section and ensure that the field 'ACD' is enabled
   • Use SAT Command "display system-parameters features". Browse to 'CALL CENTER SYSTEM PARAMETERS, EAS' section and ensure that the field 'Expert Agent Selection (EAS) Enabled' is set to yes.

   To change the customer-options settings, super user privileges are required on the Communication Manager. If these settings are not enabled, please contact Avaya or your Business Partner.

2. Add the following feature buttons to allow agent to change the state to ready or release the call. Use SAT command "change station < extension number >" and browse to the "Button Assignment" section. Add feature buttons "auto-in" and "release" where they will be convenient to the agent. If station extensions for the endpoints that will be used by the agent do not exist you will need to use the "add station < extension-number >" command in lieu of "change station < extension-number >".
3. Next step is to add an agent login ID for the agent. Use SAT command "add agent-loginID < Agent ID >" or "add agent-loginID next". Set the appropriate values for the following parameters:
   Page 1:
   • Name: Provide agent name.
   • Password: It is not mandatory to set the password.
   • Re-enter password: (re-enter the password)
   Page 2:
   • SN: Enter the skill number for the agent.
   • SL: Enter the skill level for the agent.

   Multiple skills (up to sixty) can be assigned to the agent using last two fields.

4. Once the agent login ID is created, feature access codes (FACs) need to be set for login and logout operations. Use SAT command 'change feature-access-codes' and browse to the 'Automatic Call Distribution Features' section and set the values for 'Login Access Code' and 'Logout Access Code'. You may need to modify the dial-plan via the 'change dial-plan analysis' form to configure feature access codes.
5. After provisioning the FACs, a skill based hunt group needs to be provisioned. Use SAT command 'add hunt-group next'. Set the appropriate values for the following parameter:
   Page 1:
   • Group Name:(Any Name)
   • Group Extension: Any number defined in dial plan and not configured on Communication Manager.
   • ACD: Y
   • Queue: Y
   • Vector: Y
   Page 2:
   • Skill: Y

After completing these steps, the call center setup is ready to be used:

• Register a phone.
• Go off hook and dial the Login Feature Access Code followed by the agent login ID and password (if set).
• You will hear a confirmation tone and will see the hunt-group number and skills displayed on the top-line of the display.
• Press the Auto-in button on the phone.

Note 1: The agent-loginID 'auto answer' feature should be set to 'none' and not 'all'. Agents cannot login to a hunt-group with the auto answer feature set to 'all'.

Note 2: Calling the hunt-group extension will cause any available agent logged into the hunt-group to ring. In case of 'Auto answer' mode, the available agent will hear a ZIP tone and automatically receive the call via headset.

For more details about SAT commands, please refer to the document Administrator Guide for Avaya Communication Manager 03-300509 Issue 4.0 Release 5.0 January 2008 available on the Avaya Technical Support site (http://www.avaya.com/support)

Avaya Communication Manager's version can be retrieved through the AE Services' System Management Service (SMS) interface. The SMS interface uses System Access Terminal (SAT) commands run on Avaya Communication Manager on specific objects. In the SMS interface, under Request Parameters, select Model as SoftwareVersion and Operation as List and submit the request. The Communication Manager version information is returned in the response.

There is no option to retrieve the AE Services server version using the SMS interface commands/models.

The CTI link status shown as mntBusy would indicate that CTI link is taken out of service at Communication Manager. This is the result of executing a System Access Terminal (SAT) command 'busy-out cti-link X'. This is could be verified by looking at the command history using SAT command list history. If this is the case, then the CTI link could be brought back in service using the command 'release cti-link X'.

The reason for AE Services reports the link as talking while Communication Manager reports the link as mntBusy (maintenance busy), is that the maintenance states are local to Communication Manager and not reported to the far end of the link (i.e., on the AE Services server's side).

Avaya does not classify individual components or parts of our software products. Application Enablement Services has received an export classification of 5D002.c.1 ENC Unrestricted. Products written that interface to AE Services APIs need to be classified separately by the manufacturer.

If an application is receiving the error INVALID_OBJECT_TYPE while attempting to invoke a MakeCall() request, it most likely indicates a provisioning mismatch on Communication Manager.

If the application is registering itself using Device, Media and Call Control (DMCC) APIs and using MakeCall() to activate a feature such as service observing, then the error could be due to an codec mismatch between what was specified while registering the DMCC device and the ip-codec-set provisioned on Communication Manager. The application needs to set a codec type which is valid for the network region/codec set that it is registering into. To verify which codecs are supported by the network region, follow these steps:

1. On Communication Manager's System Access Terminal (SAT) terminal, type the command list registered-ip-stations ext XX, which will display information associated with extension XX's registration including its network region value.
2. Check the codec set assigned to the network region by using the SAT command display ip-network-region n, where n is the network region number obtained in the previous step. Find the codec set number (X) under the Media Properties section.
3. Next, use the SAT command display ip-codec-set X, where X is the ip-codec-set obtained in the previous step, to view the supported codecs in this set.
4. Make sure that the codec sent in the registerDevice request is in the ip-codec-set.

Please refer to Administrator Guide for Avaya Communication Manager 03-300509, Issue 4.0, Release 5.0, January 2008 for more details on the SAT commands.

On the S8300 and S8500 Communication Manager servers, there are a maximum of 300 monitored VDNs per server. On a S8700 Communication Manager server, there is a limit of 10,000 monitored VDNs per server. This is not an AE Services limitation, but is imposed by the size of a data structure in Communication Manager. There is no coded limit to the number of VDNs that can be entered into the AE Services Security Data Base.

Application Enablement Services (AE Services) provides TSAPI and JTAPI SDKs to develop call center centric applications. These APIs provide the relevant information about Call Centers and Agents. The APIs provide a means of getting information on the Call Center agent states as well. If an application is running on a Microsoft platform, consider using TSAPI which will provide the necessary help. If an application is using Java, using JTAPI will prove to be beneficial.

For more information regarding the APIs and SDKs, please refer to the following:

1. Avaya MultiVantage Application Enablement Services TSAPI Programmer's Reference, 02-300545, Release 4.1, December 2007, Issue 3.
2. A package named javax.telephony.callcenter within Avaya JTAPI, Release 4.2.
3. Perform a DevConnect search for "AE Services API Selector" in the SDKs/APIs area and review the information on the API Locator - AE Services API Selector web page.

All of this information is available on the DevConnect portal (http://www.avaya.com/devconnect).

If there is a requirement to use two AE Services servers (one as a backup for the other, to monitor a station), then the licenses required will depend upon how the application handles the failover scenario.

Prior to AE Services 4.2, the standard licensing approach is used and separate licenses need to be provided on both the AE Services servers to monitor the same station.

Typically, an application taking advantage of multiple registrations per device across separate AE Services servers to provide a backup control and media path will use twice the licenses that the application will on a single server.

If the application uses the second AE Services server as a cold backup, they will need twice the licenses, but the second set of licenses will be provided at a reduced cost to the customer if they are purchased in conjunction with the licenses for the primary AE Services server.

Using enterprise wide licensing allows licenses to be distributed across a set of AE Services servers, but in a failure mode, license recovery by the license server does not meet the responsiveness that a real time application would need to handle the server switchover situation with the minimum number of licenses. To robustly handle the failover situation in this environment, twice the licenses that a single server would need are required.

In all scenarios, additional switch connection links need to be licensed on Communication Manager.

CTI is a means to programmatically control the switch. If a call is triggered to a busy destination (either manually by using the physical phone, or programmatically by using the call control APIs), Communication Manager provides a busy tone to the calling station. In case of a CTI application monitoring the call, Communication Manager sends a CTI event to the application indicating the cause of the failure. If no further action is taken after an interval of 30 to 40 seconds, the call is cleared to free up the resources it was using so that those resources may be diverted to other calls. If the CTI application wishes, it can either trigger a clearing of the busy call and then place a replacement call, or it can wait until Communication Manager clears the call (and provides relevant events to indicate the same) and then initiate new calls.

In a transfer scenario, when an off-PBX call is transferred to a monitored device, the transferred event shows that a transfer has occurred with the transfer party number. When TSAPI/JTAPI/DMCC does not have information to provide for a party in a call, it provides dynamic device identifiers instead. These identifiers are of the form 'Tnnnn#' (e.g. T1234#). In certain call scenarios, while a party's number may have been available to Communication Manager, it (the number) is not provided to AE Services (and thus to CTI applications). For example, assume that a call originates on trunk A and terminates to station B, and station B answers the call and subsequently transfers the call to station C. If station C is the only monitored station of the group, then in the transferred event, the information regarding party A will show up as a dynamic device identifier, and A's identity will be unknown to the CTI application. In this case, the AE Services server just provides a trunk reference (a dynamic device ID) at the transferred monitored device C. Since the AE Services server has no information about the calling party (the off-PBX number) because Communication Manager did not provide calling party number, AE Services server provides a dynamic device Id as the off-PBX calling party's number. If instead, there are monitors on B and C prior to originating the call, then in the transferred event, the monitor for C will be provided with A's identity (assuming that A's identity was provided).

Avaya Aura BDE can be procured from DevConnect by logging into the DevConnect Web portal (http://www.avaya.com/devconnect) and following the procedure outlined below:

1. Select Procurement under Membership Tools in the left-hand navigation menu.
2. At the first Procurement page, select Access DevConnect Procurement Benefits
3. At the next page, under Enter a Procurement Request, select Request Procurement.
4. At the Procurement Offers page, expand the Developer Environments & Remote Labs section and select Avaya Aura Basic Development Environment (BDE)
5. Complete the Shipping Information section and submit your order request.

For more information about how to procure Avaya Aura BDE, browse to Products & SDKs -> Development Tools & Configurations tab -> Avaya Aura Basic Development Environment -> How to order. Avaya Aura BDE is not available for download from the DevConnect Web portal.

Yes. You can view how many license units are being used by AE Services applications by logging in to the WebLM license manager.

1. Navigate to the AE Services server web page.
2. Click on WebLM Administration.
3. Log in with the appropriate credentials.
4. Under Licensed Products, click on Application_Enablement.
5. The Licensed Features table is displayed. The Acquired column displays the number of current licenses being used by AES applications.

For example, to view the number of TSAPI basic licenses being used, scroll down to the line that says TSAPI Simultaneous Users (VALUE_TSAPI_USERS) and look at the number in the Acquired column. This tells you the current number of TSAPI licenses being used.

Click on the link at the top of the table called View Peak Usage. A similar table will be displayed with columns indicating peak usage in the last 7 days and peak usage in the last 30 days.

TSAPI is a third party call control API. Third party call control capabilities include controlling specific calls or stations, complete routing of incoming calls, receiving notifications of events, invoking Communication Manager features and querying Communication Manager for information.

TSAPI provides services to monitor the different device types such as Automatic Call Distribution (ACD) hunt groups, Vector Directory Numbers (VDNs), stations along with call monitoring. The TSAPI interface provides call control services such as Direct-Agent Call and Predictive Dialing between two devices. The TSAPI Route Request Service Group allows the Communication Manager to request and receive routing instructions for a call from an adjunct application. The TSAPI Query Service Group describes services that allow a client application to query the switch to provide the device's state (e.g. talking state), feature state (e.g. call forwarding satus) and static attributes (e.g. device name). The TSAPI Escape Services Group allows an application to request a private service that is not defined by the CSTA Standard. Avaya has implemented a variety of services accessed through the Escape service such as Single Step Conference.

On the other hand, DMCC is the only API that provides first party call control capabilities (Device Control and Media Control). It also provides basic third party call control. Device control allows applications to manipulate and monitor the physical aspects of devices, such as buttons, lamps, the display and the ringer. Applications can simulate manual actions on devices and obtain the status of their physical elements.

Media control allows applications to access voice stream RTP data for the purposes of recording or analysis, and to send RTP data as outgoing voice streams.

DMCC provides the following four media modes:

1. Server Media: The RTP media stream is handled by the AE Services server on behalf of the application.
2. Client Media:The application handles the RTP media stream.
3. Telecommuter:The media stream is directed to a routable phone number.
4. No Media:The application is not involved in the media. The application is doing device control only.

DMCC services use a subset of the TSAPI services to provide third party call control capabilities, such as the ability to place calls, create conference calls, divert calls, reconnect calls, and monitor call control events. The DMCC service enables application developers to access Avaya Communication Manager's telephony features via the following supported CSTA services:

1. Physical Device Services and Events.
2. Voice Unit Services and Events.
3. Call Control Services and Events.
4. Logic Device Services and Events.
5. Snapshot Services and Events.
6. Monitoring Services.

DMCC also provides some private services as mentioned below:

1. Call recording, message playing and dubbing.
2. DTMF tone detection.
3. TTY character detection.

Yes, it is possible to perform a transfer to a 'ringing' destination (a.k.a. a Blind or Unattended Transfer) when the transfer destination is a VDN. While the vector may not be 'ringing' in the traditional sense, the transfer operation is supported by Communication Manager.

Follow these steps to verify the configuration of AE Services server and Communication Manager:

1. Login to the AE Services server web page:
   1. Go to CTI OAM Home -> Administration -> Switch Connections. Select the Communication Manager switch connection that has been configured and click Edit CLAN IPs. Verify that the IP address of the CLAN(s) specified in the 'Name or IP Address' column is correct (i.e. is a CLAN or procr IP address on Communication Manager). If the IP address is incorrect, correct the IP address by adding the correct Communication Manager CLAN or procr IP address(es) and deleting the incorrect address(es) by using the buttons on the 'Edit CLAN IPs' AE Services form.

      

   2. Go to CTI OAM Home -> Status and Control -> Switch Conn Summary. Verify that the status of the switch connection under 'Conn State' column is 'Talking.' If there are multiple CLANs provisioned click on Switch Connection Details and verify the state of all the CLANs is 'Talking.' If any interface is not in the 'Talking' state continue investigating.

      

   3. Navigate to CTI OAM Home -> Administration -> CTI Link Admin -> TSAPI Links. Verify that the Switch CTI link number matches the CTI link configured in Avaya Communication Manager. Use the command 'list cti-link' at the System Access Terminal (SAT) command prompt of Avaya Communication Manager to list the configured CTI links and get the correct CTI-link number.

      

      

      For more details regarding switch connection provisioning refer to Avaya MultiVantage Application Enablement Services Administration and Maintenance Guide, Release 4.2, 02-300357, Issue 10, May 2008, Chapter 2 titled AE Services OAM Administration under the section titled General CTI OAM Administration.

   4. If the status of the switch connection under CTI OAM Home -> Status and Control -> Switch Conn Summary is 'Invalid Password' under the 'Conn State' column, then go to CTI OAM Home -> Administration -> Switch Connections. Select the Communication Manager Switch Connection that has been configured and click Edit Connection and update the password. Also follow Step 2.b in the Avaya Communication Manager section below to set the corresponding password in Avaya Communication Manager. There is no mechanism to check what the provisioned password is.

      

2. Launch the System Access Terminal (SAT) for Avaya Communication Manager, use the commands below at the SAT command prompt and verify the output:
   1. list node-names IP Check if the CLAN IP or procr address that are used for the AE Services switch connection are set correctly. If the CLAN or procr IP address is not set correctly, then correct the IP address using the command 'change node-names ip'. If the switch connection uses the procr interface use the 'display ip-interface procr' command. If the procr IP address does not match that which is provisioned in AE Services, return to step 1 and change the provisioned IP address for the switch connection on AE Services.

      

      For additional details, refer to Avaya MultiVantage Application Enablement Services Administration and Maintenance Guide Release 4.2 02-300357 Issue 10 May 2008, Chapter 1, titled 'Administering Communication Manager for AE Services.

   2. display ip-services Check if the AE Services server name (hostname) has been configured correctly under the AE Services server column under AE Services Administration (page 3). Screen shot is shown in step 2.c below. Compare this to the output of the 'hostname -s' Linux command on AE Services.
3. If the problem is an 'Invalid Password,' update the password using the command 'change ip-services.' The passwords must exactly match on both Communication Manager and the AE Services Server (CTI OAM Home Administration > Switch Connections > Edit Connection).

   

4. status aesvcs cti-link Check the status of the configured CTI link. If 'Mnt Busy' is 'yes', then issue the command 'release cti-link <cti-link number>' to change the cti-link to an in-service/established state.

   

It is necessary to install the TSAPI client on each system where the TSAPI application will be installed and run. The TSAPI client can be installed using the Avaya installer for the appropriate operating system, or by providing an equivalent installer. For Windows systems, the installer must install the required dlls (CSTA32.DLL and ATTPRIV32.DLL), TSAPI client library configuration file (TSAPI.INI), and update the registry entry. For Linux systems, the installer must install TSAPI client library configuration file (tslibrc) and libraries (libattpriv.so, libcsta.so).

If an application monitors a Meet-Me Conference VDN with TSAPI or JTAPI then:

• For TSAPI the CSTA_ESTABLISHED event is not received.
• For JTAPI the state of the Connection for the Meet-Me Conference VDN does not change from CallControlConnection.ALERTING to CallControlConnection.ESTABLISHED. The CallCtlConnEstablishedEv for the Connection for the Meet-Me Conference VDN will not be received.

If an application monitors the originating party with DMCC, TSAPI or JTAPI then:

• For DMCC an EstalishedEvent will not be received.
• For TSAPI a CSTA_ESTABLISHED event will not be received.
• For JTAPI the state of the Connection for the Meet-Me Conference VDN does not change from CallControlConnection.ALERTING to CallControlConnection.ESTABLISHED. The CallCtlConnEstablishedEv for the Connection for connection of the Meet-Me Conference VDN will not be received.

As of Avaya Communication Manager Release 5.1 the interaction between CTI and Meet-Me conferencing is not supported.

Starting with AES 6.x, the Avaya Aura Application Enablement Services Overview and Specification document for each release specifies which SIP endpoints are supported along with their minimum required firmware.

Additional supported endpoint/firmware information may be found in the Avaya Product Compatibility Matrix. Select the "Application Enablement Services (Avaya Aura)" product and then choose the appropriate release. Note that AE Services Overview document contains fewer endpoints for some releases. Note also that the Compatibility Matrix requires SSO access to Avaya content.

Please consult the Overview document and Product Compatibility Matrix for the latest information on endpoints supported by AE Services.

Supported SIP endpoints may be used for CTI functionality with TSAPI, JTAPI, DMCC Call Control Services, and the Telephony Web Service. No other SIP endpoints (neither Avaya or third party) are officially supported for use with CTI.

On page 6 of the station form, the identified station must have the "Type of 3PCC Enabled" field set to "Avaya."

"Avaya Environment" must be set to "Auto". This setting is accessed through the telephone using the craft configuration interface (e.g. mute-c-r-a-f-t-#), accessing the SIP settings, and then SIP Global Settings, and then "Avaya Environment."

The cti-link on CM must be provisioned as an ADJ-IP link.

'Computer Telephone Adjunct Links' must be enabled on the 'display system-parameters customer-options' CM SAT form.  This field should be automatically enabled by your CM license when AES is purchased.  If not, please reach out to your license provider.

On the trunk group form for the trunk group that is sending the call to the SIP station, the "Numbering Format:" on page 3 must be set to private.

The station must use a TLS signaling link between the station and Session Manager.

CTI support for SIP stations begins in Communication Manager Release 5.0 coupled with SIP Enablement Services Release 5.0 and AE Services Release 4.2.0.

Avaya does not provide any load generating tools to run load tests on the AE Services server.

An Applications Enablement (switch) Connection (AEC) is a link between AE Services and a particular IP address on Communication Manager for exchanging CTI related requests and events. Each connection takes one VALUE_AEC_CONNECTIONS license. A switch connection to one Communication Manager using three CLANs and another to a different Communication Manager using two CLANs would require a total of five licenses. The "base" license for an AE Services server comes with two AEC licenses. A switch connection with one CLAN uses only one AEC license. However, if a second CLAN is configured as part of an AE Services Switch Connection, the AE Services server would consume two AEC licenses. In order to use a third CLAN, they need to purchase an additional AEC license.A connection between AE Services and a procr interface on Communication Manager consumes one AEC license.

Starting with release 5 of AE Services, AECs are no longer licensed (each system is equipped with the maximum number of licenses - 16 - by default).

AE Services APIs can be used to monitor a Hunt Group, a Vector Directory Number (VDN) and a Station. The device needs to be configured in the AE Services server device list under Security Database with the correct Device type. For a Hunt Group, the device type is 'ACD', For a Vector Directory Number, the Device type is 'VDN'. A Station is configured with type as 'PHONE'.

In TSAPI, cstaMonitorDevice()service can be used to monitor a Hunt Group or a Station, cstaMonitorCallsViaDevice()method can be used to monitor the Vector Directory Number.

In JTAPI, Terminal.addCallObserver() or Address.addCallObserver() method can be used to monitor a Station. To monitor Hunt Group, Address.addCallObserver() method is used and a Vector Directory Number is monitored using CallCenterAddress.addCallObserver().

In DMCC, Monitor start service can be used to monitor a Station. DMCC doesn't support Vector Directory Number and Hunt Group monitor.

No, a station does not have the same state as an Agent. A station can be in an Idle (on-hook), in a Busy (off-hook) or an out of service state. An Agent can be LOGGED IN or LOGGED OUT. An Agent can also be in following work mode states: NOT_READY, WORK_NOT_READY and READY.

TSAPI: the attQueryACDSplit() method is used to determine the number of Agents available in a Hunt group. The method returns the 'number of available Agents', 'Agents logged in to a Hunt group' and 'number of calls in queue' in the confirmation event.

JTAPI: the ACDAddress.getLoggedOnAgents() method returns the number of Agents logged in to a Hunt group with each Agent's current state in the confirmation event. By utilizing the Agent's current state, the number of available Agents in a Hunt group can be determined.

DMCC: In AE Services Release 6.1 and later, use:

• DMCC .NET: GetAcdSplit(String, Object), GetAgentState(String, Object);
• DMCC Java: getACDSplit(device DeviceID), getAgentState(device DeviceID, acdGroup AcdGroup).

Consult the htmldoc or javadoc for more information.

In AE Services Release 5.2 and earlier, DMCC did not provide an API method to determine the number of Agents available in a Hunt group.

A Call Center Agent reason code is a one or two digit numeric value. When a Call Center Agent changes into the AUX Work mode or logs out, depending on system and agent-loginID configuration settings, the Agent can provide a reason code. Reason Codes give Call Center managers detailed information about how Agents spend their time. This data can be used to develop more precise staffing forecasting models or can be used with schedule-adherence packages to ensure that Agents are performing scheduled activities at the scheduled times.

Avaya Communication Manager can be configured to accept reason code information in one of two ways: Forced and Requested.

With Forced reason codes, Agents can not enter AUX Work mode or log out until they enter a reason code. If an Agent enters an invalid code or fails to enter a code within the10-second timeout interval, the change is denied and the Agent remains in the current work mode.

With Requested reason codes, Agents can optionally enter a code to enter AUX Work mode or log out. If an Agent enters an invalid reason code or fails to enter a reason code within the timeout interval, the Agent enters AUX Work mode or logs out with default code 0.

Logout reason codes can only be in the range of 0 to 9, even if the 'Two-Digit Aux Work Reason Codes' option (see 'display system-parameters features', page 14) is enabled. AUX Work mode reason codes can be in the range of 0 to 9, or 0 to 99 when the 'Two-Digit Aux Work Reason Codes' feature is enabled. Each reason code can be identified with a specific name via the 'change reason-code-names' SAT form. The VuStats feature can be used to display the reason code name or number. Use VuStats or CMS to gather historical and real-time reason code statistics.

In Avaya Communication Manager, at the SAT command prompt, run the following commands and check/enable the indicated settings to enable Call Center Agent reason codes:

Note that these screens and field locations were collected using Communication Manager Release 5.1. If you are using a different switch release, the fields may be in a different location. Please consult the customer documentation for the switch release you are using to find out the field's exact location.

1. Use the "display system-parameters customer customer-options" command and verify that the 'Reason Codes' field on page 6 is set to 'y' as shown in the figure below. The Expert Agent Selection (EAS) feature on the same form must be enabled to use reason codes.

   

2. If the 'Reason Codes' or the 'Expert Agent Selection (EAS)' fields are not set to 'y', then consult an Avaya sales representative to get the feature(s) licensed for your system.
3. Use the "display system-parameters features" command to verify the type set for 'AUX Work Reason Code' and 'Logout Reason Code'. The reason code type can be set to either 'forced' or 'requested'. With 'requested', an Agent has to enter a reason code when entering the AUX Work mode or Logout mode, but the Agent is not forced to do so. Use 'forced' to force an Agent to enter a reason code when entering the AUX Work or Logout mode. By default, the value is 'none'. When the setting is 'none', an Agent does not have to enter a reason code when entering the AUX Work mode or Logout mode. When the 'Two-Digit Aux Work Reason Codes' feature is enabled on this form, reason codes can be in the range of 0 to 99, otherwise they range from 0 to 9. Refer to the figure below:

   

4. Use the "change system-parameters features" command to change the Aux Work and Logout Reason Code Type to either 'forced' or 'requested' as required.
5. Check the settings for Agent ID using the command "display agent-loginID <agentID>" and verify that the 'Aux Work Reason Code Type' and 'Logout Reason Code Type' fields are set to either 'forced', 'requested', 'none' or 'system'. The value can be changed using the command "change agent-loginID <agentID>" on the SAT. When the reason code type is set to 'system' agents use the reason code type set in the 'system-parameter features' screen. Setting the agent's reason code type to values other than 'system' forces the agent to use the mechanism that is specified on that agents agent-loginID form. Refer to the figure below:

   

6. If two digit reason codes are being utilized, use the 'change cti-link <cti-link number>' command to set the 'Two digit AUX Work Reason Codes' option to 'y'. The option must be enabled to send the two digit reason code over the ASAI link. This field can only be set to 'y' when 'Two-Digit Aux Work Reason Codes?' on the 'Feature-Related System Parameters' screen is set to 'y'.

   

The UUI data size depends on the Private Data version and Communication Manager release. The UUI data size was increased from 32 bytes to 96 bytes beginning with Private Data version 6 and onwards. Prior to Communication Manager Release G3V8, the maximum length of the UUI data was 32 bytes. Beginning with Release G3V8, the maximum length of UUI data was increased to 96 bytes. So to access the maximum UUI data capability, Communication Manager Release G3V8 coupled with Private Data version 6 or later is required.

UUI and UCID information can be sent over digital trunks (ISDN, H.323 or SIP) from one Communication Manager to another Communication Manager. For ISDN and H.323 trunk types, to allow this information to be forwarded, on page 3 of the trunk-group form, the 'Send UUI IE?' and 'Send UCID?' parameters must be set to 'y'. Starting with Communication Manager release 5.1, SIP trunks always send UCID and UUI.

In order for Communication Manager to receive UCID information from a remote system, be sure to set UUI Treatment on page 3 of the trunk group form to 'shared'.

For Communication Manager to generate a UCID value for a call, on page 5 of the system-parameters features form, the UCID option titled 'Create Universal Call ID (UCID)?' must be enabled (set to 'y') and the "UCID Network Node ID:" value must be set. Please note that the above page numbers are with respect to Avaya Communication Manager Version 5.1.

A Tlink (or T-Link) represents a communication link between the AE Services server and Communication Manager. When a communication channel (i.e. switch connection) is provisioned between AE Services server and Communication Manager a Tlink is created dynamically by the TSAPI service running on AE Services server. There can only be one Tlink for one AE Services server-Communication Manager combination. However, multiple Tlinks can be created between one AE Services server and multiple Communication Managers or vice-versa.

Each TSAPI/JTAPI application needs to specify one of the available Tlinks at the time of opening the ACS stream with AE Services server. The chosen Tlink will then be used to communicate with Communication Manager for the application (for the opened stream).

The Tlink is of string type and has following format:

AVAYA#Switch_Connection#Service_Type#AE_Services_Server_Name for example AVAYA#CMSIM#CSTA#AESSIM, where

1. AVAYA is a fixed constant.
2. Switch_Connection is a unique name assigned to identify a switch (i.e., Communication Manager). In general, hostname of the switch is assigned as the name of Switch Connection in the AE Services server.
3. Service_Type: refers to the CSTA service type. It can be either of the following:
   • CSTA - For using unencrypted TSAPI Link (non-secure connection).
   • CSTA-S - For using encrypted TSAPI Link (secure connection).

   The CSTA versus CSTA-S service types specify whether or not encryption is used between the application and the AE Services server.

4. AE_Services_Server_Name represents the host name of the AE Services server which is assigned during the AE Services installation.

When the calling device number appears in a format such as "T94#1", then it indicates that the Communication Manager has no specific device information or ANI about the calling device. This number is generated by the TSAPI service and it is used to represent the unknown device.

Each device that can be observed and manipulated needs to be referenced across the 'computer-supported telecommunications applications (CSTA)' service boundary. There are basically two ways of identifying the device.

Static Device Identifier: A static device identifier is stable over time and remains constant and unique between calls.

Dynamic Device Identifier: When a call is connected through a trunk with an unknown device identifier, a dynamic trunk identifier is created for the purpose of identifying the external endpoint. It may use different dynamic identifiers to represent endpoints connected to the same actual trunk at different times. A trunk identifier has a prefix 'T' and'#' within its identifier (for example, T538#1, T4893#2). Therefore, when 'getDeviceOnCall().getDeviceIdentifier(). getExtension()' is used on a 'SnapshotCallResponseInfo' object, it returns the correct extension number in case of an internal extension, which is a static device identifier. For External Extension number, it returns 'Txxxx#1' only. When a call arrives, trunk group/member information is available in private data associated with the Delivered and Established events. A dynamic device identifier will remain constant through out the life of a call.

For further details, refer Avaya MultiVantage Application Enablement Services TSAPI for Avaya Communication Manager Programmer's Reference 02-300544 Release 4.1 December 2007 Issue 3, page number 148.

Universal Call IDentifier (UCID) is a unique call identifier across switches and the network. UCID is a random number generated by the first switch Communication Manager (CM) receiving the call over a ISDN, H.323 or SIP trunk where UCID is enabled on the switch and UCID is not present in the incoming call request. A valid UCID is a null- terminated ASCII character string. If there is no UCID associated with a call, the UCID contains ATT_NULL_UCID (a 20-character string of all zeros). This parameter is supported by private data version 5 and later. UCID is a combination of time stamp, call sequence number of the CM and the network node number.

A sample UCID looks something like this:

00001001411206342646

where,

00001: Network Node Number, 00141: Call ID and 1206342646: Number of elapsed seconds since the epoch start of 12 AM 1/1/1970.

Note: applications should not break down the UCID into its component parts. The UCID value should be used as an 8-byte binary or 20-digit decimal value without making use of the individual parts. Avaya reserves the right to change the content of the UCID fields; therefore, using the UCID as an "opaque" value would prevent incompatibilities in the future.

A Tlink represents a communication link between the AE Services server and Communication Manager. AE Services supports both secured and unsecured Tlink. In a secured Tlink, the information is encrypted before sending to Communication Manager. Whereas, in an unsecured Tlink, there is no encryption involved.

An AE Services server administrator can configure a Tlink for secured (encrypted) or unsecured (unencrypted) communication. For more information on how to administer a Tlink, as encrypted or unencrypted, refer the section titled "Administering TSAPI Links in AE Services OAM" in chapter 2 of the document titled "Avaya MultiVantage Application Enablement Services Administration and Maintenance Guide Release 4.2 02-300357 Issue 10 May 2008", available at http://www.avaya.com/devconnect.

The application will receive an ACSERR_NOSERVER error if the application is trying to access an encrypted (secured) Tlink without making sure that the following points hold true:

1. The protocol should be mentioned as "CSTA-S" instead of "CSTA" in the Tlink used for opening the stream. For example, the application must use "AVAYA#SWITCH#CSTA-S#SERVERNAME" as the Tlink.
2. The TSAPI Client library version must be 4.1.0 or later.

AE Services' Device, Media and Call Control (DMCC) Java Media Stack provides the TTY character detection functionality. A sample code snippet is available for demonstrating TTY character detection. This code snippet is bundled in the DMCC Java SDK (in the cmapijava-sdk\examples\src\sampleapps\clientmediastack\tty directory). The DMCC Java SDK is available from the http://www.avaya.com/devconnect web site.

For more information on TTY character detection, please refer to the section titled "Media Session & TTY Control" in the document titled "Application Enablement Services Device, Media and Call Control API Java Programmers Guide, Release 4.2, An Avaya MultiVantage Communications Application, 02-300359, Issue 4, May 2008", available on http://www.avaya.com/devconnect.

For AE Services server 3.0: To log-in into WebLM installed on AE Services server, refer to the steps below:

1. Open the AE Services server's web page using https://<IP address of AE Services server or Host name of AE Services server:8080>/WebLM/LicenseServer.
2. Click on License Administration and log-in using the WebLM administrator username and password.
3. The default username is 'admin' and the password is blank. At the first login to WebLM, the server instructs the user to set the new password. This new password must then be used for subsequent logins.

For AE Services server 3.1 or 4.X: To log-in into WebLM installed on AE Services server, refer to the steps below:

1. Open the AE Services server's web page using https://<IP address of AE Services server>.
2. Click on WebLM Administration and log-in using the WebLM administrator username and password.
3. The default username and password is 'admin' and 'weblmadmin' respectively. At the first login to WebLM, the server instructs the user to set a new password. This new password must then be used at subsequent logins.

To confirm the availability of TSAPI or DMCC licenses in the AE Services server, follow the steps below:

1. Open the AE Services server's OA&M web page using https://<IP address of AE Services server>.
2. Click on WebLM Administration and login with the WebLM administrator username and password. The default username and password is 'admin' and 'weblmadmin' respectively. At the first login to WebLM, the server instructs the user to set a new password. This new password must then be used at subsequent logins.
3. Click on the Application_Enablement option. The page on the right displays the list of licenses that AE Services server contains in a tabular format. Verify the availability of the following TSAPI or DMCC licenses on this page by checking the corresponding license's field:
   1. TSAPI Simultaneous Users (VALUE_TSAPI_USERS): This license is consumed when any of the basic TSAPI functions like Make Call (cstaMakeCall), Call Monitor (cstaMonitorCall), etc. is performed. One TSAPI Simultaneous User license is required for each device.
   2. TSAPI Simultaneous Advanced Users (VALUE_TSAPI_ADVANCED_USERS): This license is consumed when the application wants to use features like Adjunct Routing (RouteSelect, RouteSelectInv), Answer Machine Detection, Selective Listening (Hold and Retrieve), Switch Classified Outbound Calls (MakePredictiveCall).
   3. DMCC DMC (VALUE_DMCC_DMC): The value in the column named Licensed corresponds to DMCC DMC license which exists in the AE Services server. If no DMCC DMC license is available, an attempt will be made to allocate an IP_API_A license from Communication Manager instead. One DMCC DMC or IP_API_A license is used for each registered DMCC station.

Several other types of licenses are required to take the full advantage of TSAPI's capabilities. For more information on the various licenses required on AE Services server to use TSAPI, refer to the document titled "Avaya MultiVantage Application Enablement Services Overview, 02-300360, Release 4.2, May 2008, Issue 5" available on http://www.avaya.com/devconnect.

Beginning with AE Services version 4.0, the peak license information can be accessed by logging in to WebLM on AE Services server. Refer to the steps below:

1. Open the AE Services server's web page using https://<IP address of AE Services server>
2. Click on WebLM Administration and login with the WebLM administrator username and password.
3. The default username and password is 'admin' and 'weblmadmin' respectively.
4. Click on the Application_Enablement link to view the standard license file.
5. Next, click on the 'View Peak Usage' option as shown in the figure below:

   

   A page similar to the one shown below will be displayed:

   

   The peak license usage for each license type is shown as a specific value and a percentage. Columns are provided for current usage, along with peak usage during the last 7 and 30 days for each license type.

AEP stands for Application Enablement Protocol. The transport link established between the AE Services server and Communication Manager makes use of one or more AEP connections to send ASAI and DMCC Call Information Services messages over TCP/IP. An AEP connection is a secure TCP/IP connection between the AE Services server and a CLAN (that resides on Communication Manager) or Processor Ethernet (procr) interface. An AEP connection license is required on the AE Services server for each AEP connection (socket) from the AE Services server to Communication Manager.

A transport link is required for ASAI services. TSAPI, JTAPI and CVLAN all make use of ASAI services. The DMCC service uses ASAI services for Call Control and Call Information Services.

By default, the AE Services server contains two AEP licenses (synonymous with CLAN or procr connections) which can be used to set up communication links with Communication Manager. For configuring additional AEP connections, the user needs to purchase an AEP connection license for each AEP connection.

The AE Services server supports a maximum of 16 AEP connections, i.e.16 different Communication Managers can be connected to a single AE Services server. However, to provide failover capabilities, Avaya strongly recommends configuring 2 AEP connections per Communication Manager. Thus, an AE Services server should only be connected to a maximum of 8 (eight) Communication Managers. For high traffic situations, a single Communication Manager may require up to four AEPs to be configured (five if the customer wants a backup link).

Starting with AE Services release 5.2, AEP (Application Enablement Protocol) connections are no longer licensed. Each AE Services server supports up to 16 AEP connections. The WebLM interface no longer shows the number available and the number in use. To Calculate the number in use, you must check the status pages (Status > Status and Control > Switch Connection Summary [Active/Admin'd AEP Conns]) to access similar information.

With prior releases, to confirm the availability of the AEP connection license in the AE Services server, follow the steps below:

1. Open the AE Services server's OA&M web page using https://<IP address of AE Services server>.
2. Click on WebLM Administration and login with the WebLM administrator username and password. The default username and password is 'admin' and 'weblmadmin' respectively. At the first login to WebLM, the server instructs the user to set a new password. This new password must then be used at subsequent logins.
3. Click on the Application_Enablement option from the left column menu. The page on the right displays the list of licenses that the AE Services server contains in a tabular format. Verify the availability of the AEP connection license on this page by checking the corresponding license's field:
   • Application Enablement Connections (VALUE_AEC_CONNECTIONS): The value in the column Licensed corresponds to the number of connections that the AE Services server is licensed with.
   • Application Enablement Connections (VALUE_AEC_CONNECTIONS): The value in the column Acquired corresponds to the number of connections currently in use in AE Services server.
   • By clicking on the "View Peak Usage" link in the right panel, you can see the maximum license consumption by the server since the data was last reset.

When the calling device's number appears in a "Txxx#x" format (such as "T94#1"), it indicates that Communication Manager has no specific information about the calling device (ANI). A number in the "Txxx#x" format is generated by AE Services and this number is used to represent the unknown device.

Each device that can be observed and manipulated needs to be referenced across the Computer-Supported Telecommunications Applications (CSTA) service boundary. There are two ways of identifying a device:

1. Static Device Identifier: A static device identifier is stable over time and remains constant and unique between calls. All internal extensions are static device identifiers.
2. Dynamic Device Identifier: When an off PBX number is involved in a call, a dynamic trunk identifier is created for the purpose of identifying the external endpoint. AE Services may use different dynamic identifiers to represent endpoints connected to the same trunk at different times. Typically, a trunk identifier has a prefix 'T' followed by xxx representing a number and a '#' character followed by a number (for example, T538#1, T4893#2 etc). The trunk identifier is generated by the internal logic in the AE Services server.

Avaya Communication Manager supports trunk-group configuration for sending the calling device name and number information with the outgoing calls. Follow these steps to change the trunk-group configuration for sending the calling device name and number information (ANI) with the outgoing calls:

1. Go to Communication Manager's SAT Terminal.
2. Type "change trunk-group <trunk_group_number>" and use Esc+n to navigate to page 3.
3. Set both the 'Send Name' and 'Send Calling Number' fields to 'y'.
4. Use Esc+e to save to the changes.

If an AE Services server is not licensed for a service AT ALL, then for 30 days after bringing up AE Services for the first time, the server can use that unlicensed service. After AE Services has been running for 30 days, the license file will be imposed. If the server is licensed for a service, then that licensing restrictions are imposed from day one.

For example on day one a license file with 10 TSAPI licenses and no DMCC licenses is installed on a new server. Then no more than 10 TSAPI licenses can be allocated starting at day one. An unlimited number of DMCC licenses can be used (there may be restrictions imposed by Communication Manager on other necessary licenses such as IP_STA). After 30 days, unless a new license file is installed, no further DMCC functionality can be utilized.

As long as the memory requirements are met for AE Services (2GB of RAM) and the operating system are correct (Red Hat 5.2), then a software only version of AE Services would be supported by Avaya Global Services.

System Management Service (SMS) is no longer licensed. Application Enablement Protocol (AEP) transport connections are no longer licensed.

No.

No. While it is not possible for an application to specify a limit for the allowable number of monitors, an application can try to put the monitor on the call/device, and will get a particular return code if the number of allowed monitors on that object type has been exceeded.

For more information on the return code and capacity limits, refer section "Chapter 10: Monitor Service Group" and "Communication Manager CSTA system capacities" in the document "Avaya MultiVantage Application Enablement Services TSAPI for Avaya Communication Manager Programmer's Reference 02-300544", available on http://www.avaya.com/devconnect.

Center Vu Computer Telephony CVCT is both a product name and a commonly used name associated with Computer Telephony Integration (CTI) API technology provided by Avaya (and its precursor Lucent Technologies) to get call events and perform call control of the Avaya DEFINITY Enterprise Communications Services (ECS) or Communication Manager server. The CVCT product technology has been migrated to the Applications Enablement (AE) Services product. CVCT and its successor 'Avaya Computer Telephony Server' (Avaya CT Server) provided CVLAN and TSAPI API interfaces. CVCT interfaced to Avaya DEFINITY ECS and Communication Manager using a DLG link to a MAP-D circuit pack and to client applications using either the CVLAN or TSAPI protocols. Support for both of these protocols (as well as others) is provided by AE Services.

Given that the MAP-D interface supported a CVLAN interface most customers utilized the TSAPI capabilities of the CVCT product almost exclusively to avoid using 'another box' in the connectivity path. Many individuals referred to the predominate CVCT protocol as 'CVCT' instead of 'TSAPI.'

CVCT implements an older version of the TSAPI protocol than current generation AE Services servers provide. However, applications developed to work with the CVCT product can be easily migrated and run against the AE Services product. The CVCT product is manufacture discontinued and maintenance and devconnect support are no longer available.

Agent Logged On and Logged Off events occur for call center agents associated with an ACD Split. An ACD split is a special form of a hunt group.

In order to receive Agent Logged On and Logged Off events, the application needs to setup a device monitor on the hunt group extension(s) that the agents are logging into using the TSAPI or JTAPI API. An application can make use of cstaMonitorDevice() method to setup a device monitor. In the cstaMonitorDevice() method, the application can specify the ACD/hunt group extension to be monitored in deviceID parameter. If multiple ACD splits need monitored then multiple cstaMonitorDevice() requests need to be sent.

For more information on cstaMonitorDevice() method, refer section "Chapter 10: Monitor Service Group" in the document "Avaya MultiVantage Application Enablement Services TSAPI for Avaya Communication Manager Programmer's Reference 02-300544", available on http://www.avaya.com/devconnect.

Note that in AE Services Release 6.0 the full complement of TSAPI methods are planned to be exposed in the DMCC API. In that timeframe, using the DMCC API to access this information should be possible.

The Universal Call ID (UCID) is a unique 8-byte binary tag assigned by Communication Manager to each call upon call origination or upon entry into Communication Manager, if the call is not already associated with a UCID. UCID allows tracking of calls from cradle to grave within a private network of Communication Manager systems when they are connected via ISDN, H.323 and SIP trunks.

Products such as Call Management System (CMS), Intuity Conversant, and Avaya Computer Telephony support UCID. However, most of these products do not provide the internal 8 byte binary value at the user interface that is assigned by Communication Manager and sent over the ASAI link within the UCID Information Element. Instead, they provide a converted ASCII string of 20 characters.

Different CTI APIs make UCID available in either the converted format or the 'raw' hex format (sometimes presented as a decimal value).

Note: applications should not break down the UCID into its component parts. The UCID value should be used as an 8-byte binary or 20-digit decimal value without making use of the individual parts. Avaya reserves the right to change the content of the UCID fields; therefore, using the UCID as an "opaque" value would prevent incompatibilities in the future.

The conversion algorithm to convert from the 64 bit value to the 20 digit ASCII character format is as follows:

1. group the UCID bytes into three groups: the most significant two bytes are grouped as group 1, followed by the next two bytes as group 2, and the least significant four bytes as group 3;
2. convert each group of bytes into their decimal equivalent;
3. group 1 is a signed number whose converted value ranges from 0 through 32,767; This field is the UCID Network Node ID from the 'change system-parameters features' form.
4. group 2 is an unsigned number whose converted value ranges from 0 through 65,535; In practice this number is limited to the maximum number of simultaneous calls supported by the Communication Manager processor.
5. group 3 is an unsigned number whose converted value ranges from 0 through 4,294,967,295; This value is elapsed seconds since Jan 1, 1970.
6. each conversion is done independently, right justified, and zero filled;
7. all three groups are concatenated to form the 20-character ASCII string in the order: group1group2group3 An example of the above conversion algorithm is the following. If Communication Manager assigns a UCID whose value, represented in hex and given over the ASAI link, is 0x04 0x0B 0x13 0xEC 0x3F 0xDE 0x12 0x34; the converted 20 character ASCII string would be, 01035051001071518260, whereas some CTI interfaces may present this as a single decimal number 291348506300256820. The 20 character ASCII string is what CMS, Intuity Conversant, and TSAPI and JTAPI Avaya Computer Telephony provide to the user interface or application, whatever the case may be. DMCC XML provides the decimal equivalent of the Hex value. Via the DMCC Java and .NET SDKs formats matching the TSAPI/JTAPI 20 character representation are available.

Hence, applications receiving a raw UCID (binary value) need to convert it to the 20 character ASCII equivalent in order to compare it to a UCID provided by CMS, or any of the adjuncts mentioned previously. Note that the above UCID does not include the UCID Information Element Identifier and length bytes, but just the value (8 bytes). Also, note that in this example byte 0x04 is the most significant byte, while 0x34 is the least significant one.

Since AE Services release 5.x and prior does not support IPv6, connections between the two systems will need to continue to use an IPV4 network infrastructure.

In cases where IP information is provided to AE Services applications through AE Services APIs from Communication Manager data bases (e.g. System Management Service - SMS), AE Services will pass through the IP Address information it receives from Communication Manager. For example, the response to the System Management Service request with operation=list, model=RegisteredIPStations can contain both IPv4 and IPv6 addresses in the unlikely event that the customer environment has been configured with a mixture of IPv4 and IPv6 address domains.

pplication developers should note that the format for deviceIDs that contain IPv6 IPs in the AE Services release that does support IPV6 (targeted for 6.1) will have many more colons than previous device IDs. Thus any parsing of the deviceIDs is discouraged.

• IPv4 [4452:cm_server1:100.120.140.160:0]
• IPv6 [4452:cm_server1:1001:6209:a3dc:0:217:8ff:bc7e:e50f:0]

Additionally as can be seen in the example above, the maximum length of the device ID will increase. Having static (fixed length) storage space for device IDs may also be the source of problems in an environment where IPv6 deviceIDs are utilized.

Avaya does not support the 3rd form of IPv6 addresses, or so-called IPv4-mapped IPv6 addresses such as "::ffff:192.168.1.1".

Enterprise-wide licensing does not currently support IPv6 addresses (as of July, 2010).

Start by reviewing http://tools.ietf.org/html/draft-johnston-sipping-cc-uui-08' (or if you can find a more recent version of the draft use it. People have implemented against the -08 successfully.

UUI in a SIP REFER works with CM 5.2 and subsequent releases. Earlier releases of Communication Manager do not support UUI in the SIP REFER.

You will know if Communication Manager recognized where you put UUI if it appears in the INVITE going to the refer-to party. That will imply you are very close to having it included in TSAPI (if not done) in the delivered event for a monitor at the destination station.

It is required that the "UUI Treatment" setting on page 3 of the trunk group form (the trunks that are used to interface to the SIP endpoints), is set to "service-provider". Any other setting will cause UUI in the REFER to be ignored.

Here is an example REFER, see the red text in the Refer-To header for how to transmit UUI.

REFER sip:309a98@135.9.72.60:5061;transport=tls SIP/2.0 From: sip:30130@avaya.com;tag=8030a117a787dc1f144728f46900 To: "5359626" <sip:30998@avaya.com>;tag=-78e1eb8d4703d55e6657ac6e_F135.9.72.60 Call-ID: 9_1f53d70a5f9d2c0f6657ac6a_I@135.9.72.60 CSeq: 1 REFER Max-Forwards: 70 Route: <sip:135.9.71.53:5061;transport=tls;lr> Via: SIP/2.0/TLS 135.9.97.67;branch=z9hG4bK0e4651ca787dc1f244728f46900 User-Agent: Avaya CM/R015x.00.0.822.0 Contact: "ASAI UUI Test VDN" <sip:30130@135.9.97.67:5061;transport=tls> Refer-To: <sip:30012@135.9.71.53?User-to-User=00C81031313232333334343535363637373838%3Bencoding%3Dhex> Content-Length: 0

Within the User-to-User portion the 00CB10 breaks down as follows 00 - That is a required field that per the Q931 spec. It can either be set to "04" or "00". When the UUI is parsed out just allocate for this octet and ignore it. Normally it is set to "04" which is supposed to mean that all the data bytes are in IA5 format (International ASCII). However when the UUI is shared, the original data format is mixed, binary, hex and ASCII. It can also be set to "00" when there is no ASAI user data included in the shared UUI string. Note that if the UUI is unshared (Service Provider), first octet (00 or 04) is the PD and the rest is all ASAI user data with no App ID.

C8 - is the App ID for ASAI user data. Treat it as a constant. 10 - length in octets of information following (Since SIP sends the octets encoded in ASCII the 31 represents one octet's worth of information).

The remaining information 31313232333334343535363637373838 is an ASCII encoded string of 1122334455667788

You can subscribe to certain product notifications through www.avaya.com/support. Use a browser to go to the landing page, and find the link for "Feeds and Notifications." Then click "E-Notifications." Login using your SSO credentials (you need to have purchased Avaya equipment to get SSO credentials.. use your 'sold-to' number to get a SSO). Then click MAXIMIZE, and then E-notifications, scroll the left window to locate "Avaya Aura Application Enablement Services" and then in the right window check the boxes you are interested in. Note: the slider does not operate like a MS Windows? slider?. If you click somewhere along the slider it does not page forward, it goes to an absolute location.. click and drag it to see all the content of a window.

There are two key pieces of information provided in TSAPI, JTAPI and DMCC messages that help applications track calls; those are the CallID and UCID. There are scenarios (conferences and transfers) where the CallID and UCID mapping changes. CTI applications can be notified of the UCID assigned to a call, and UCID services must be explicitly enabled on Communication Manager ...

Read the full answer here.

See How to import AE Services CA Trusted certificate to applications in order to establish secure connection?

It is possible to use a combination of Single Step Conference (SSC) and Selective Listen Hold (SLH) to extract individual media streams for each party in a call. That way, it is possible to implement a "stereo" recorder where each person is recorded separately or to provide a clean stream to a biometric analyzer. As an example, consider a call between 1001 and 1002 where we want to record 1001's voice only at recorder 2001 and 1002's voice only at 2002:

1. Use DMCC to register the recorders (2001 & 2002) in Main dependency and Client media mode.
2. You will need at least one TSAPI/JTAPI/DMCC Call Control monitor on a device involved in the call to know when a call is made.
3. Make a call between 1001 and 1002.
4. SSC 2001 and 2002 into the call in Listening mode. At this point they both receive media from 1001 and 1002.
5. SLH with subjectConnection = 2001 and selectedParty = 1002
6. SLH with subjectConnection = 2002 and selectedParty = 1001
7. At this point, 2001 receives media only from 1001 and 2002 receives media only from 1002.

Notes:

• For conference calls, the application would need to perform extra SLHs.
• It is possible to undo SLH using Selective Listen Retrieve (SLR)
• Selective Listen Hold (and Selective Listen Retrieve) is available to TSAPI, JTAPI and DMCC applications.
• Apart from any TSAPI Basic and DMCC licenses that are needed, SLH also requires a TSAPI Advanced License.
• A "stereo" recorder, as in the example, increases the number of recording ports required.
• There is a limit to the number of recorders that can be added to a call. There is also a limit to the numbers of voice paths that can be blocked using SLH. See the FAQ Is there a limit to the number of "stereo" recorders that can be created using Selective Listen Hold? for details.
• For detailed information on Single Step Conference, Selective Listen Hold and Selective Listen Retrieve, see the document titled TSAPI for Avaya Communication Manager Programmer's Reference(select Releases in the left navigation and then the Downloads tab).
• It is not possible to use this mechanism with Multiple Registration recorders without impacting the media stream received by the 'main' device.
• When a call is being recorded (SSC or SO recorders), a warning tone can be sent to the participants. This warning tone is included in the media sent to each recorder, even when all parties are selective listen held. You can get more information on warning tones in the Playing a Recording Warning Tone section of the appropriate DMCC Programmers Guide (select Releases in the left navigation and then the Downloads tab).

A stereo recorder is one where each party of the call is recorded into a separate recording. It is possible to achieve this using several Single Step Conference (SSC) recorders and the Selective Listen Hold (SLH) feature of TSAPI/JTAPI/DMCC. For more information on this, see the FAQ How can I get an individual media stream for each participant in a call? The ability of an application to add a stereo recorder to a call is limited by two things:

1. The Maximum Number of Parties in a Conference No more than 6 participants can be conferenced together in a call. Each recorder added to a call counts as a participant so adding extra recorders will limit the number of real participants that can be conferenced into the call.
2. The Maximum Simultaneous Selective Listening Disconnected Paths There is a limit to the number of listen paths that can be blocked at any one time on Communication Manager. As of release 7.1, for small switches, the maximum is 75, for large switches the maximum is 300. The document Avaya Aura Communication Manager System Capacities Table will show which applies to your Communication Manager. To illustrate this, consider a conference call between 1001, 1002 & 1003. 2001, 2002 & 2003 are SSCed into the call to act as recorders and Selective Listen Hold is used so that 2001 hears only 1001, 2002 hears only 1002 and 2001 hears only 1003. Assume that 2001, 2002 & 2003 do not send media into the call and so do not need to be blocked from listening to each other.
   • SSC 2001 to the call
   • Send SLH for 2001 so it doesn't hear 1002 (1 path blocked)
   • Send SLH for 2001 so it doesn't hear 1003 (1 path blocked)
   • SSC 2002 to the call
   • Send SLH for 2002 so it doesn't hear 1001 (1 path blocked)
   • Send SLH for 2002 so it doesn't hear 1003 (1 path blocked)
   • SSC 2003 to the call
   • Send SLH for 2003 so it doesn't hear 1001 (1 path blocked)
   • Send SLH for 2003 so it doesn't hear 1002 (1 path blocked)

   At that point, 2001 hears 1001, 2002 hears 1002 and 2003 hears 1003. 1001, 1002 and 1003 can talk and hear each other. 6 listen paths have been blocked for this call.

   This means that on a large Communication Manager configuration, 50 simultaneous three party calls can be recorded like this (6 * 50 = 300). Alternatively, 150 two party calls can be recorded (2 * 150 = 300). On a small Communication Manager configuration, 12 simultaneous three party calls can be recorded like this (6 * 12 <= 75). Alternatively, 37 two party calls can be recorded (2 * 37 <=75).

Yes. There is an interaction between Selective Listen Hold (also referred to as Selective Listen Disconnect) and DMCC Multiple Registrations where a Multiple Registrations (MR) device may be impacted. Call media is defined to be - A generic reference to any one of, or a collection of voice (RTP) traffic, in-band tones, DTMF via RTP payload type indications, and out-of-band DTMF events for calls. An application may utilize one or more of these types of call media. The use of the Selective Listening Hold service by any deployed application to modify the call media to a specific extension will impact the call media received by any/all other applications using the Multiple Registrations feature that are associated with the same extension.

Application developers who are working with call media, should review the DevConnect White Paper Recommended Guidance for DMCC Applications Utilizing Call Media for further information.

Yes. Selective Listen Hold (SLH) also referred to as Selective Listen Disconnect prevents the flow of voice and DTMF signals coming from a specified party from being received by another party in the call. In many cases blocking that pathway is valuable functionality. One use of this functionality is with a PCI-DSS application to prevent a contact center agent from hearing personal information supplied by a party in the call. However, if a recording device that is using DMCC Multiple Registrations, is receiving the agent's audio stream, when SLH is invoked to reconfigure the audio the agent is receiving, the recording application is also blocked from receiving the voice and DTMF information sent by the far end party. This may or may not be expected by the call recording application. Another case could be that the Multiple Registrations application is doing analytics on the audio stream; when SLH is invoked, the analytics application may be prevented from receiving audio or DTMF events unexpectedly and undesirably. Since multiple applications may be involved at a customer site (one using Multiple Registrations and the other invoking SLH), but both operating on the same party in the call, the MR application may be unaware that the interaction is occurring. If being in full control of the receipt of all of the audio and DTMF information occurring in a call is required by the application, then the guidance in the DevConnect White Paper Recommended Guidance for DMCC Applications Utilizing Call Media should be reviewed for further information about how to properly design for this interaction.