noted... I will pass this information to the documentation tech pubs group responsible for the document, it will show up in the 5.0 version :( Thanks for pointing it out, sorry for the pain it caused.

John

Alex,

Avaya MultiVantage®
Application Enablement Services
TSAPI for Avaya Communication Manager
Programmer's Reference
02-300544
Release 4.2
May 2008
Issue 4

It is available on the DevConnect web site (www.avaya.com/devconnect) and on www.avaya.com/support

Alex,
I looked at the release 4.1 version of the TSAPI for Avaya Communication Manager Programmer's Reference and see the statement about the CSTA defined device types that TSAPI Service does not use. The list includes 'ACD Group'. While I am not versed in the unances between CSTA terms and use in the methods, I can assure you that using the cstaMonitorCallsViaDevice and using a VDN or Hunt Group (ACD) Extension will provide you with call eventing for calls traversing those entities on Communication Manager. You can use the TSAPI Exerciser to quickly prove this to yourself (assuming you have a CM and AE Services system to work with).

There are some interactions as a call travels between monitored VDNs and when a VDN controls a split that you may want to read up on and do some testing via the TSAPI Exerciser to make sure you are certain you understand.

John

The error codes are documented in the TSAPI for Communication Manager Programmers reference manual which is available on the DevConnect Portal or support.avaya.com.

Error code 35 indicates The device in the API call is administered to be supported by a different Tserver.

thus I surmise the login you are using is not properly configured to have access to the device you are trying to access. Try changing the login to have unrestricted access to the security data base using the web OA&M GUI under administration > Security Database > CTI Users

I believe the person responsible for handling the front end of procurement is out of the office due to a health issue. His voice mail says he will be back in the office Thursday.

Please start by reading and following the instructions for configuring your AE Services server to support TSAPI. This will walk you through what provisioning and licensing you need to perform to utilize TSAPI services. The instructions can be found in AES Installation and Upgrade Guide for Bundled Server
document # 02_300356_5.pdf They are also in the software only guide.

You need to also make sure you have followed the README instructions in regard to configuring the TSAPI.PRO file on the client PC.

If openStream fails, your PC is not communicating with the AES, so everything should fail. I recommend using theAES documentation and the TSAPI for CM programmers documents as starting points for configuring and validating a TSAPI install.

Trying to learn TSAPI by just working with the client is not a good starting point.

in the left panel of the devconnect portal, there is a link for 'procurement request'. Click it..

locate 'Request Procurement' from the center panel. Click it.

Locate the solution name "ACM/AES DMCC" Click Request Procurement from that page.

Locate TSAPI SDK v4.1. Click Details/Order
Fill in form, read and agree to Terms and Conditions.
Click Place Order

You will now receive the following form...
Thank you for your Procurement Request. You will receive an email notification when your invoice is available typically within the next 2 business days. Log back into this DevConnect portal, go to the "Procurement Request" page and take the "Get Current Procurement Status and Change History" link to reach a link to get your invoice. At that time you can pay by check, bank wire, or online using a credit card.

From this point continue to follow the instructions provided to you.

TSAPI provides sample applications for the Windows client. For more information about these code samples, see "Code Samples" in Chapter 2 of the AE Services TSAPI for Avaya Communication Manager Programmer's Reference, 02-300544.

Specifically, there is no sample code for acquiring agent information as part of the SDK. One fo the tools contained in the SDK is the TSAPI exerciser which would allow you to exercise any method in the TSAPI SDK, and access the agent information using the techniques that I have described earlier.

FYI, the TSAPI SDK is a C++ implementation. There is no .NET TSAPI SDK available. If you look around in the forums, there is a member who has posted some information about a wrapper for the SDK that apparently allows its use with .NET. I can not vouch for that wrapper in any way other than to say it that it exists.

Matthew,
the topic of licensing is supposed to be straightforward, and to some extent it is, however it must not be well explained because it draws a lot of questions.

A monitorCallsVIaDevice on a VDN takes no licenses.
A license is consumed when the application does something to a call it has discovered exists (through its monitor on the VDN).

A monitor on a station (typically an Agent), takes a TSAPI Basic User license as long as the monitor is active. The strategy is (mostly) that one station monitor == one TSAPI Basic User license.

There are moments where that last paragraph does not hold true (like a call monitor), or during some queries (e.g agentState) or set (e.g. setCallForwarding). But by in large the licenses that are held the longest are the station monitors.

hope this helps,

Unfortunately it is a for fee item. We used someone elses ASN.1 compiler producing it and owe them royalities. You can procure it through devconnect portal, click on procurement, and then any solution. I believe it is the last product in the list.

If you want at the exerciser that I used, you can do an equivilant thing through the JTAPI exerciser. The JTAPI SDK is a free download on the portal. Do a devConnect search to locate the page it is on.


John

I emailed it again, I did not receive a bounce indication.
It is supposed to work. I have not tried it for a long time.
I have not seen/heard any complaints regarding its usability.
If you have problems please make us aware.

first keep in mind that JTAPI is a Java API to access TSAPI services on the AES. Thus sometimes the information you seek will be hiding under TSAPI product areas. In this case there is a FAQ in the TSAPI area describing what functionaliy the TSAPI advanced license controls.
When is the TSAPI advanced license required?

A TSAPI advanced user license is needed if the application wants to use any of the following features:
- Adjunct Routing (RouteSelect, RouteSelectInv)
- Answer Machine Detection
- Selective Listening (Hold and Retrieve)
- Switch Classified Outbound Calls (MakePredictiveCall)
- ISDN Redirecting Number
- Phantom Calls
- CTI Stations

Our review of the log files indicates that there are networking issues between both the client application and the AES as well as between the AES. These network errors need resolved by you or the IT department responsible for this installation. There are long periods of connectivity loss between the AES and both of the servers it is trying to communicate with. Getting a copy of the /opt/mvap/logs/TSAPI/* log files after you setup trace maxk may shed light on issues you have after you resolve the network stability problems.... start with a ping between AES and the C-LAN on CM you have configured the switch connection to terminate on. I preceive it fails for long periods of time. That is probably what is causing the issues with setting up a device monitor.

The AES software load is fairly old at 3.1.0 (current build is 3.1.4... you should consider upgrading).

It should. I can not confirm it because I have not done it.
Not much satisfaction in that response, but that is all I've got to give.

I suggest you start your reading with alook at call control services in DMCC and device monitoring in TSAPI, and a callObserver on a terminal or address in JTAPI.