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:
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:
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.
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
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:
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.
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 stateTCP Up - transitional state indicating a socket connection has been established and there is handshake negotiation occurringTCP Down - A state indicating a socket connection was created and has come down for a variety of reasonsIdle - An indication that the connection is not talking, and something is preventing it from entering the TCP statesInvalid client - An indication of a provisioning errorOffline - 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:
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:
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:
Check the connection state on the AE Services OAM page.
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:
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:
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:
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,
Then check the power settings in VMWare (these instructions are for Workstation).
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:
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:
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:
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:
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.
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 >".
Multiple skills (up to sixty) can be assigned to the agent using last two fields.
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.
Use SAT command 'add hunt-group next'. Set the appropriate values for the following parameter:
After completing these steps, the call center setup is ready to be used:
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:
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:
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:
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.
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:
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:
DMCC also provides some private services as mentioned below:
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:
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.
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.
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:
If an application monitors the originating party with DMCC, TSAPI or JTAPI then:
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.
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.
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:
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.
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
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:
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:
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:
For AE Services server 3.1 or 4.X: To log-in into WebLM installed on AE Services server, refer to the steps below:
To confirm the availability of TSAPI or DMCC licenses in the AE Services server, follow the steps below:
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:
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:
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:
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:
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. 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:
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.
Application 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.
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:firstname.lastname@example.org:5061;transport=tls SIP/2.0 From: sip:email@example.com;tag=8030a117a787dc1f144728f46900 To: "5359626" <sip:firstname.lastname@example.org>;tag=-78e1eb8d4703d55e6657ac6e_F22.214.171.124 Call-ID: 9_1f53d70a5f9d2c0f6657ac6a_I@126.96.36.199 CSeq: 1 REFER Max-Forwards: 70 Route: <sip:188.8.131.52:5061;transport=tls;lr> Via: SIP/2.0/TLS 184.108.40.206;branch=z9hG4bK0e4651ca787dc1f244728f46900 User-Agent: Avaya CM/R015x.00.0.822.0 Contact: "ASAI UUI Test VDN" <sip:email@example.com:5061;transport=tls> Refer-To: <sip:firstname.lastname@example.org?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 ...
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:
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:
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.
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.