JTAPI Event Indicating Resume from Hold

[Bliss]

Hello.

JTAPI notifies about a terminal which entered Hold state by sending a CiscoTermDeviceStateHeldEv event.

When terminal resumes from Hold state, a CallCtlTermConnTalkingEv event is sent.
But, this event is also sent on other scenarios, e.g. when a call is initially answered.

How could a Resume-from-Hold scenario be distinguished?

[dstaudt]

The device state server feature works at the Terminal level, and provides a consolidated overall device state and events.

If only one call is in progress, and it gets held, then you would see CiscoTermDeviceStateHeldEv as you mention.  If that call gets un-held, then I would expect to see CiscoTermDeviceStateActiveEv.  However, if there are multiple calls, then things could get confusing, as CiscoTermDeviceStateHeldEv will only be sent when all calls are on hold, but CiscoTermDeviceStateActiveEv would be sent if any of those held calls gets un-held.

So:

CiscoTermDeviceStateActiveEv - if any call on the device is in Dialtone, Dialing, Proceeding, Ringback, or Connected (including incoming call)

CiscoTermDeviceStateHeldEv - if all calls are held

It may make more sense in your case to not use the device state server feature, but instead monitor individual calls/terminals.  To do so you would add observers for CallObserver/CallControlCallObserver, and would receive CallCtlTermConnHeldEv when the call is held, and CallCtlTermConnTalkingEv when it is un-held.

[Bliss]

Thank you, @dstaudt, for the elaborate and useful answer. It is much appreciated.

Yet, one thing is still unclear to me: Is the CallCtlTermConnTalkingEv event only fired when device is Un-Held, or may it also be fired on other circumstances, such as when call is initially answered?

My aim is to identify the specific scenario of resuming from hold, in a stateless machine - processing and responding to one event at a time (without keeping track of previous events), which is a given operation constraint.

[dstaudt]

CallCtlTermConnTalkingEv can be fired any time the call moves to TALKING state, as you say being un-held is one of several such transitions.  AFAIK you can only determine a resume has happened by understanding/remembering the previous state, i.e. it was being held -  there is no unique indication of a resume, as there is with the held event.

[Bliss]

Thanks much! Again, your inputs are useful.

I've empirically seen CallCtlTermConnTalkingEv events on Resume-from-Hold scenarios, with CallCtlCause=214.
I couldn't find any mentioning of this value - not in the Developer-Guide document and not in JTAPI's code (in the CiscoCallEv class, or elsewhere). Searching the web also didn't yield useful results.

Would you happen to know the meaning of this value, and whether or not it is directly related to Un-Hold scenarios?
Or, possibly, do you have the option to find out?

[dstaudt · Accepted solution]

Good catch, as 214 seems to be CAUSE_UNHOLD:

This info is part of the JTAPI API spec, now owned by Oracle.  The Cisco JTAPI JavaDocs that are part of the SDK cover only the Cisco extension packages - perhaps unhelpful, but I assume due to licensing/copyright.

You can find this kind of info on Oracle's JTAPI spec page: https://www.oracle.com/java/technologies/jtapi.html

Click through and select the 'Specification / API' download link.  This has the uncompiled Java class interface files:

(Came across this, could be interesting: https://github.com/carloca68/jtapi

)

Note this is for JTAPI 1.4, whereas Cisco JTAPI is based on the 1.2 version (for which I couldn't find a download) - at least for this kind of item, it should be the same.

[Bliss]

Thanks a lot for helping out! This is very useful.
Blessings.

[Bliss]

Hello, @dstaudt.

Could you please pay attention to another question I've posted, here?