« Back to Cisco JTAPI Questions

RE: JTAPI 9.1.1

Combination View Flat View Tree View
Threads [ Previous | Next ]
JTAPI 9.1.1
Answer
2/8/13 3:10 PM
Looking at the latest JTAPI APIs.
 
I see the CiscoTerminal has states:

CiscoTerminal.DEVICESTATE_ILDE
CiscoTerminal.DEVICESTATE_ACTIVE
CiscoTerminal.DEVICESTATE_ALERTING
CiscoTerminal.DEVICESTATE_HELD
CiscoTerminal.DEVICESTATE_UNKNOWN
CiscoTerminal.DEVICESTATE_WHISPER

And I also notice the events coming in the Observer for the Terminal :

TermConnRingingEv
TermConnActiveEv
 
 
Question:  How much in real time the state of the Terminal is updated with the event I would observe in the observer thread ?  For e.g. If a Terminal is getting a incoming call  (RINGING), I would see the TermConnRingingEv event in the observer thread. If I just want to check the state of that terminal to determine if it is Ringing or not, can I just check for the CiscoTerminal.DEVICESTATE_ALERTING  ?
 
 
Arvind
 
Flag

RE: JTAPI 9.1.1
Answer
2/8/13 3:49 PM as a reply to Arvind Sharma.
Connection states can change in means on milliseconds.
You can check current state through CiscoTerminal.getDeviceState() == CiscoTerminal.DEVICESTATE_ALERTING.
Meanwhile the state of teminal can change already. Not a big deal if you want to show current state to user, but might be not that good if you plan to record missed calls.
Flag

RE: JTAPI 9.1.1
Answer
2/8/13 3:57 PM as a reply to Alexander Anikin.
Okay. So if my application wants to show some kind of UI with dynamically changing Terminal State - it can use the Obsrever events. And if the app just want to show the Terminal state at that point in time, checking CiscoTerminal.getDeviceState() would do the job.
 
Correct ?
 
I guess I am debating which route it will be more robust. The events also change very quick in an active call  (Incoming Call->Alerting-?Ringing etc). Would relying on the Terminal state will be more accurate ??
 
 
Thanks!
 
Arvind
 
 
Flag

RE: JTAPI 9.1.1
Answer
2/8/13 4:08 PM as a reply to Arvind Sharma.
Your basic assumptions are good ones: if you just need a snapshot of the device at a point in time getDeviceState will be highly accurate.  If you want to display states dynamically/real-time (event driven) use an observer.

I would say observer/events is 'more robust' in the sense that you can get both static and dynamic functionality that way, but if you just need a snapshot - for example an instantaneous decision to send a call to a device based on whether it is busy or not - then observer/events (and the state machine, threading and handling overhead) may be 'overkill'.
Flag