I am a .net developer with some Java knowledge and (from long ago) some C++. I need to obtain some agent information from (I assume) the AE Server. Since I cannot use C# unless my company purchases a DMCC license I am looking for opinions regarding Tsapi OR jtapi.

What agent state information are you looking for? I'm not sure if we are talking about Call Center Agents (agent-loginID form on CM), or stations. Either way, a DMCC license is only needed if you are going to be registering a terminal to do 1st party call control. 3rd party call control uses TSAPI licenses whether you are using TSAPI, JTAPI, or DMCC ( they all use TSAPI for 3rd party call control). At that point it just becomes a matter of what your preferred programming language is, TSAPI is C++, JTAPI is Java, and DMCC is .NET/Java/XML.

If you are trying to get Agent states then you have to poll for that using a getAgentState method. This would require a TSAPI license for each concurrent pending request to get agent state as TSAPI only uses the license for the duration of the request (usually just milliseconds).

If you are trying to monitor stations to get call events (Delivered, established, etc.) then you would need a TSAPI license for each station that is being monitored. The license would be in use for the entire time that the station has a monitor on it.

Since you are a .NET guy I would definitely go with DMCC .NET. The SDK is free to download on this website. Then you would just have to figure out how many TSAPI licenses you need. As a general rule you should have 1 TSAPI license for every concurrent Agent/station handling calls, but it really depends on your requirements.

please review this sample app
http://www.devconnectprogram.com/site/global/products_resources/avaya_aura_application_enablement_services/educational_resources/sample_applications/tsapi/agent_view/index.gsp

it is TSAPI but the general principals would apply to all three APIs.

Regardless of if you use JTAPI or TSAPI or DMCC you will need TSAPI licenses.

You ONLY need the DMCC license if you REGISTER a DMCC device, which you will not need to do if all you are interested in is agent state...

Thanks John and Craig. That information helps. I have a more basic (naive?) question though. I need to know what agent ID logged on to the phone taking the call. I do not need this in real time and can therefore store the information in a DB table. At a 30,000 foot level can you gents explain the bits? What is "running with" the TSAPI stream and where is this entity running? Might it be a web service that is called from a piece of code writing to a table?

30,000 foot view
TSAPI Application opens a 'stream' (session/connection) with AE Services and provides certain credentials and information about which version of the protocol it will use.

one approach

TSAPI application monitors the hunt group extensions (splits) where agents of interest may login cstaMonitorDevice (will subsequently trigger logged on/off events)
TSAPI application queries the hunt group extension to find out what agents are alreay logged in. attQueryAgentLogin()
TSAPI application queries each agent to find out which extension it is logged in from. cstaQueryDeviceInfo()

Second approach

If you 'know' there is a call on extension 1000, you can send a query asking if there is an agent ID associated with extension 1000.
Of course since the agent/extension binding changes over time, you are best to do this while the call is active. cstaQueryDeviceInfo()

Unfortunately none of this is available through a web service a thick client will be needed.

Quite informative, John. Thanks

to know there is a call on extension 1000, either the person using the phone has to tickle the application manually (not very reliable), or you can create a cstaMonitorDevice() on extension 1000 (and others like it where agents may login) and have that monitor send the application events when there are calls on the device. The latter consumes a lot of TSAPI licenses... I will leave it to you to know when there is a call at a device that interests you since I infer you may have a handle on that.