JTAPI CallCenter SDK

[avc930146307620]

Strangely, it looks like JTAPI does not have call ids. We are more interested in monitoring calls, not the agents, and we'd like to collect as much CDRs as possible. Having a way to identify calls would be very useful...

[avc861193901584]

You will need to do a bit of digging if you want to get any information that is not exposed in the standard JTAPI interfaces.

Something like this would work:

javax.telephony.Call call; // get this from the event
if (call instanceof LucentV5CallInfo) {
LucentV5CallInfo lucentV5CallInfo = (LucentV5CallInfo) call;
this.ucid = null;
try {
if (ucid == null && call.getState() != Call.INVALID) {
ucid = lucentV5CallInfo.getUCID();
}
} catch (TsapiPlatformException e) {
}
}

If you don't need the information in real-time and the customer has an Avaya CMS, there's an addon called ECH (external call history) that writes a CSV to a sftp server of every single call that it monitors.

[avc930146307620]

Adam, thank you.

It looks like a lot of useful info can be extracted from the TS implementation classes in addition to the call ids.
There are in fact two "call ids", one is called just call id, and it's usually a number < 10000, another one is called ucid and it's a long string.
What's the difference between them? Is the call id is local in some sense, and the ucid is the universal one?

The ECH you suggest can be very useful. We'll try it if it turns out that some CDR-related info we need cannot be obtained via JTAPI, but so far so good.
BTW, how long can be the delay between the real call end time and the time when the ECH info is available?

[avc861193901584]

Yes, one of them is the TSAPI call ID (the call ID for events in the TSAPI session) and the other is the UCID. The UCID is guaranteed to be unique in an environment with multiple (properly configured) Communication Managers by including a node ID and epoch timestamp in addition to the TSAPI id.
TSAPI ids can be reused for different calls and change as the call gets transferred, UCIDs will never be reused for different calls and can remain the same value as calls get transferred.


It depends on how busy the system is, but if I remember correctly, ECH is usually sent within 5 minutes of the call segment completing.

[avc930146307620]

We tried to add call listeners to VDN. The address for the VDN is created, and the address listener can be added to the address, but the call listener cannot. What do we do wrong?
Thank you!

[avc861193901584]

Hi Gene,

Are there any specific errors? Be sure that your listener class implements javax.telephony.callcontrol.CallControlConnectionL istener and that the address is a VDN (and not a Hunt Group Extension).

Adam

[avc930146307620]

Hi Adam,

In fact, our goal is to listen on ALL the calls going through our customer. They provided us only with two agent ids / extensions. Call listeners cannot be added to the agents, only to the terminals (as you mentioned above).
We were able to figure out a couple of station ids and after some digging, we found 170 station ids. We added the call listeners to all the stations terminals.
The problem is that we cannot be sure that we have the complete list of stations. And if it's not complete, we will miss some calls. And if that list is dynamic, we will have to update it permanently.
One way to have the complete list of stations is to use SMS, but it gives too much freedom to modify their configuration, so they did not give us the permissions for the security reasons.
Is there any way to figure out the complete list of stations in our situation? Or should we just ask them directly for such a list?
We also know a couple of VDNs (hopefully, they are VDNs :-) ) and tried to use them, but an attempt to add a CallConnectionListener to them results in an error "failure to monitor device".

Thank you!
Gene.