I think this FAQ covers the information you need.

Q.    How can an application get agent state change events using TSAPI?

A.   The Automatic Call Distribution (ACD) extension should be monitored in order to get the agent logged in and out state change events. Use the cstaMonitorDevice() request with the ACD/Hunt Group extension as the input parameter to establish this monitor. By putting a monitor on a hunt group the application will get events every time agents login or logout. To stop getting such events, use the cstaMonitorStop()request.

After establishing the monitor, the ACD/hunt group should be queried to see if there are already any agents logged in. Use the attQueryAgentLogin() request with the hunt group's extension for this task. The system's response includes the number of logged in agents, and the station extension's of the logged in agents. The application should then use the cstaQueryAgentState() request to discover the status of each logged in agent (e.g. Work mode, Talk mode, etc). The application can use the cstaQueryDeviceInfo() request to discover the station extension to agent extension binding.


To receive other agent state change events, the agent extension or station extension must be polled by the application using the cstaQueryAgentState() request.

Ibrahim
Ok, I think I understand (at least I can whittle it down to two possible scenarios, or maybe there is a third that exists that I don't 'see just yet.

You developed a DMCC applicatin that does call recording.
To accomplish attaching the recording device to the calls occuring at a station you create a DMCC device in client media mode (lets call this party A) that does the call recording piece.

You invoke service observing from A against party B (the party who's calls you want to record).

Party B is using an IP softphone.

You then use the .NET SDK to create a call control monitor for B (in your writeup you say you use TSAPI which is a different SDK, but you go on to talk about registering which is a DMCC operation, so right here your writeup has some conflicts that are confusing, so I have written out the two possibilities I see at this point of divergance).

At the point you register the DMCC device that is monitoring B, the real B IP Softphone gets unregistered.

Answer, don't register the DMCC device that is monitoring B. Just set-up the monitors. You will get call control events. You can try this with the dashboard and verify you get call control events. However I dont believe these call control events give you agent information... thus I dont think this is what you are doing.

Additional comment regarding posible scenario 1
If this is the scenario you are working with you must be using a Communication Manager release 4.0 or older and AES 4.0 or older. With CM 5 and AES 4.1 you can have a DMCC monitor & register against an IP Softphone without causeing the IP Softphone to be logged off.


Alternative interpertation of your scenario....

You developed a DMCC applicatin that does call recording.
To accomplish attaching the recording device to the calls occuring at a station you create a DMCC device in client media mode (lets call this party A) that does the call recording piece.

You invoke service observing from A against party B (the party who's calls you want to record).

Party B is using an IP softphone.
You use the TSAPI SDK to monitor device B.

(there is no 'registration' with TSAPI so your write up is confusing). The TSAPI monitor does not cause the IP Softphone to be unregistered. All is well. Thus there is still something I dont _really_ understand regarding what the problem is.

have your tried to use the sample apps (e.g. callLog)? That provides a working framework for an application that will work its way up to monitoring a device.

do you have the SDB disabled in theAES? or are you working with an unrestricted login? If not please do so so we can exclude those potential issues (although they should throw a different error).

is this a software only AES, or a bundled server?

I'm guessing that the log files represent an attempt to use the JTAPI exerciser (some time stamps of what you tried and some explanation of your efforts would be most helpful in trying to understand the data you have provided).

At the point the monitor start is invoked it is rejected with a GENERIC_OPERATION_REJECTION.
Typically that error indicates some software error occured in the AES.

I am going to ask someone more familiar with AES internals than I to go through the traces with me and see if he can shed some light on what may be occuring.

What is the procedure for enabling and accessing the AE Services logs for TSAPI?

2. If the file named 'tracemask' does not exist, create a file called 'tracemask' and insert the one of the following lines in it:

The problem here seems to be that you have an old version of the .NET simpleIVR app (which has been renamed RPTC (record playback transfer conferene).

Ismael,
I just sent it to your hotmail account. I don't know if there is a message size limit on that ... it is a 2MB file.

John

What version of AES are you using (enter swversion at a linux prompt to find out if you don't know)?

ResourceUnavailable would indicate that either the credentials supplied did not have permission to access the device passed (i.e. it is not in the SDB), or when the request was passed to CM, the device was of the wrong type or not provisioned on CM. Looking at the trace files can shed light on this. You may need to add
asailink=0xffffffff
to the flags in the /opt/mvap/conf/tracemask file to get enought detail.

The errorno 2 issue indicates that the socket was closed at the point that the AES tried to send the response to the query. Do a IP sniff and verify which server closed the socket. Out side of a bunch of messages being sent from the AES to your app and filling your queue to the point it overflowed, or a handshake issue (neither of which seem likely), the AES does not close the socket.

John

Were you successful in using the JTAPI exerciser?
Did you try it from the same machine that you are running your applicatin on?

I will look into that error code and see if I can get an explanation.

On the surface this says that the AES tried to send your system (192.168.210.74) a message, and it couldn't. Exactly what error code 2 is I will have to investigate.

John

I guess I don't understand what the question is here. Could you please restate the environment you are working with, the scenario, and then perhaps I can give you the direction you need.

An agent can not be logged in unless the station they are using is registered.

my email to your email address listed in your devConnect profile bounced. Can you check it and make sure it is correct and respond to the form.

Thanks.

Please enter a devconnect support ticket with the information you have provided and we will start digging into what may be the cause.

The resource I use is chapter 6 of
CentreVu-Computer-Telephony
Release 9.1, Version 1
Telephony Services
Administration and Maintenance
Issue 1
November 2000,

I will email you a copy of the document as I don't see it on line.

Due to low interest level, and resource allocation constratints, support for Solaris and other OS like HP/Unix
and SCO UnixWare isno longer available.

Follow the TSAPI instructions.. in the tracemask file insert a line that reads

asailink=0xffffffff

adding diagnostics like this will impact the server's performance. Please remember to disable this when you are done.


Rules for writing tracemask files (/opt/mvap/conf/tracemask)

1) Each line that starts with a # is a comment. Comments are
particularly useful as reminders on tracing levels
2) Any text after a # is a comment and is ignored.
3) All other lines are name/value pairs, e.g., trans_serv=256
4) Spaces are NOT ignored -- don't use white space unless you
mean it, e.g., trans_serv = 512 is wrong, but trans_serv=48
is OK.
5) Values can be specified in hexidecimal by prefixing them with
0x, e.g., trans_serv=0x100 is the same as trans_serv=256.
6) The names all and default have special meanings. Default is
used when the server's name is not specified. All is used as
a mask to apply to the Debug setting, i.e., it is OR'd with the
debug setting. For example, if all=1 and default=8, then the
Debug value is 9. Also, if the tracemask file contained two
lines, default=0 and all=0x1f000, then libtrans.so would be
traced in all servers.
7) The name must match AppName for the program being traced, all or
default. The currently defined AppName's are as follows:

AppName libtrans.so libasai.so liblicense.a
---------- ----------- ---------- ------------
trans_serv yes no yes
asailink yes yes yes
CVLAN no yes yes
DLG yes no yes
DAPI yes no yes
TSAPI no yes yes

Note: tracing for a server includes the libraries that it calls


Trace Levels for All Servers (except TSAPI)
-------------------------------------------
(0x00000001) 1 Trace msgs to/from switch

(0x00000002) 2 Trace from server startup
(0x00000002) 2 Trace from OAM request

(0x00000004) 4 Trace from the read msg path
(0x00000008) 8 Trace from the send msg path

Trace Levels for Specific Servers
---------------------------------
(0x00000800) 2048 asai_link Trace from locking asai_map

(0x00000800) 2048 trans_serv Trace from MAP links

(0x00000400) 1024 CVLAN Trace from database
(0x00000800) 2048 CVLAN Trace from connection list locking

(0x00000010) 16 TSAPI Trace from AAO - CSTA/ASAI translation
plus ASAI association state management
          mechanism replacing KLOG_AAO, KLOG_DCAAO,
          KLOG_ENAAO, KLOG_MSAAO, KLOG_QUAAO,
          KLOG_RTAAO, KLOG_SFAAO, KLOG_TCAAO and
          KLOG_TMAAO
(0x00000020) 32 TSAPI Trace from MO - Call/Device Modeling &
Monitoring mechanism replacing KLOG_MAO,
          KLOG_MO, KLOG_CCO and KLOG_DMO
(0x00000400) 1024 TSAPI Trace from messages audit thread in
(0x00000800) 2048 TSAPI Trace from message for common/trace.out
TSAPI/audit_trace-130.out

(0x00000010) 16 DLG Trace from database operations
(0x00000020) 32 DLG Trace from ESAI protocol processing
(0x00000040) 64 DLG Trace from delayed socket close
(0x00000080) 128 DLG Trace from connect/disconnect processing
(0x00000100) 256 DLG Trace from connect/disconnect processing
(verbose)
(0x00000200) 512 DLG Trace from message trace (verbose)
(0x00000400) 1024 DLG Trace from sleep start/finish
(0x00000800) 2048 DLG Trace from mutex acquires and releases

Trace level settings for libtrans.so
------------------------------------

(0x00001000) 4096 Trace from locking the transport maps
(0x00002000) 8192 Trace from transport API calls
(0x00004000) 16384 Trace from message allocation
(0x00008000) 32768 Trace from timer
(0x00010000) 65536 Trace from message queue

Trace level settings for libasai.so
-----------------------------------

Tracing is always on.



Example of /opt/mvap/conf/tracemask
-----------------------------------
#
#
# Common Trace Settings
#
# Everything off
#
#default=0
#
# Everything on
#
#trans_serv=0xffffffff
#CVLAN=0xffffffff
#asailink=0xffffffff
#TSAPI=0xffffffff
#perf=0xffffffff
#
# Everything on except mutex tracing and message tracing
#
#trans_serv=0x0001e80e
#asailink=0x0001e00e
#CVLAN=0x0000800e
#TSAPI=0x00000c3e
# To see the messages to/from CM for TSAPI use
#TSAPI=0x00000c3f
#
#DLG=0x0001e7fe
#

default=0
trans_serv=0x0001e80e

you need to use TSAPI or JTAPI and monitor the hunt group for agent login/outs (and do a query to see who is already logged in when you connect). Then discover the agentID to extension associations using the methods that are supported. Look into the TSAPI for CM programmers guide for more details (this document is on the devconnect web site.