Blogs

Check out the new content on the Cisco Developer Network reflecting the New & Enhanced features in Cisco Unified Communication Manager 9.1.
See the new 9.1 JTAPI Documentation ...Read More

 

The Unified Communications 9.0 Partner Bundle packages Cisco’s Collaboration application software for our Collaboration partner community to leverage for their internal lab or demonstration systems. The 9.0 version is now available for order. Learn More >> ...Read More

 

Developer Partners,

Cisco announces the availability of our 2012 Developer Partner presentations shared at CiscoLive San Diego.

Please log into the Cisco Developer Network using your Partner UserID to download this content.

Access these presentations here: http://developer.cisco.com/web/cdc/devforumpreso PARTNER LOGIN REQUIRED
...Read More

 

Developer Partners,

Cisco announces the availability of our 2012 Developer Partner presentations shared at CiscoLive London.

Please log into the Cisco Developer Network using your Partner UserID to download this content.

Access these presentations here: http://developer.cisco.com/web/cdc/devforumpreso PARTNER LOGIN REQUIRED
...Read More

 

Cisco Technology Developer Partners,

Cisco is proud to announce the availability of our Cisco Unified Communications System Release 8.6 Not-For-Resale software bundle on Cisco Marketplace (Partner Login Required).

To purchase the latest Unified Communications NFR Software bundle
- Navigate to Cisco Marketplace
- Login using your Cisco.com UserID ...Read More

 

Showing 1 - 5 of 30 results.
Items per Page 5
of 6
First Previous Last

Forums

« Back to Cisco JTAPI Questions

RE: JTAPI 9.1.1

Combination View Flat View Tree View
Threads [ Previous | Next ]
toggle
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

Collateral


No files available