I am trying to locate where the monitorCrossRefID is inside the JTAPI event data returned upon an unsolicited event and how to extract it. I need this ID because I plan on running multiple monitors inside a single connection to our AES server. In TSAPI, I was able to extract this from the CSTAMonitorStartConf event then compare that to the xRefId field returned with each event following.

I am establishing a "monitor" by getting the terminal object from the provider passing the extension of the physical phone, then adding a call listener. I receive events just fine for said monitor and I am able to extract the CallId, CallingDeviceId, and CalledDeviceId. However I am unable to locate the monitorCrossRefId. I do believe I found it while inspecting the event data returned, however it is located in an object of type TSDevice, which I dont know how to access/parse.

I have implemented the ConnectionListener and its methods for my event handlers, which seems to work for getting the events I am looking for but I am unsure how to parse the data returned for the monitorCrossRefID. Does anyone have any ideas? Let me know if you need any other info about my code.

Thanks

I am not as familiar with JTAPI as DMCC but my understanding is that JTAPI is very much Object Orientated. It abstracts away things like monitorCrossRefID.

When an application receives an event, it is often interested in which object the event is for, as I think you are here. TSAPI does this by using the monitorCrossRefID to map between the station/VDN and the event.

With JTAPI, you start a monitor using something like Terminal.addCallListener(TerminalConnectionListener mylistener). To process the events, you implement TerminalConnectionListener with, say MyTerminalConnectionListener. If you create a new MyTerminalConnectionListener object for each Terminal that you monitor, the MyTerminalConnectionListener object that receives the event can be mapped to the associated Terminal.

For example, you can save the Terminal as a member variable in the MyTerminalConnectionListener object or you can manage a global Hashmap that maps [TerminalConnectionListener -> Terminal].

If you look at the AgentView sample application on Devconnect, you will see something similar done (Hashmap). AgentView only uses this to stop the correct listener but there is no reason not to use the same mechanism to map events to monitored terminal.

Martin