Reboot your cluster and try again. I've come across this a couple times but with the older series of phones (05, 60, 70 and IPC).
If that doesn't help and if your app doesnt' have a call listener, try adding one even if you do nothing with the events - it helped me when I had trouble accessing and setting forwards through jtapi (even there's no reason there should be a call listener in the first place.. it's just one of those things)
Well, the Call Listener was a good thought but it actually stopped my CiscoIPPhoneText object from going thru (no errors, it just disappears somewhere)...the CiscoIPPhoneExecute that was sending tones was unaffected.
I sent on your advice about rebooting the cluster to our customer...see if that helps...
Weird.. I have a dummy call listener (I need it so that I can get forward settings via JTAPI), and I can send CiscoIPPhoneStatus objects as well as URIs to clear the CiscoIPPhoneStatus.
In another app of mine, I do the same with the CiscoIPPhoneStatus objects and on top of that I send URIs to push buttons, URIs to clear the call log, and CiscoIPPhoneText items.. and I have a call listener (well, callcontrollistener really) which does a lot of heavy lifting. I've placed an order to get a bunch of 41s and 61s in my lab (as well as the rest of the new models).. and I'll check how my two apps run on those devices.. I'll let you know should I find any problems.
The program is a simple Text Messaging app that also allows tones to be sent to the phone via using the ringtones over and over again in a loop...I just keep sending CiscoIPPhoneExecute commands for every tone...I had to add a one second delay between each push because the different models of phones act differently; the 7912s / 05s will play a tone immediately as the command comes in (cutting off the currently running tone), 70s will insert their own pause between tones, and all other models I've used will collect the execute commands and play the tones back to back to make a nice loop.
I'm using various flavors of the 4.1 Call Manager and it's included JTAPI files...it just depends on the customer. My application is a Servlet module running under Tomcat 5.0.
I'm implementing ProviderObserver for the Provider.addObserver(). However, I'm using CiscoTerminalObserver instead of TerminalObserver for the Terminal.addObserver() that gets attached to all the endpoints...maybe that's causing something...
Once I get a CiscoTermInServiceEv.ID in the terminalChangedEvent message pump, I spam the endpoint with however many CiscoTerminal.sendData() commands I need to make before calling the Terminal.removeObserver at the end to free up the observer.
My company is a reseller, and for the more robust phone applications from other vendors that we sell, I see that they are using HTTP consistently for pushing XML objects to the phones. They use JTAPI for monitoring phone states and manipulating Calls. No JTAPI for CiscoTerminal.sendData()...I wonder if they know something or if their programs naturally evolved that way from older versions...
Anyway, my customer with the problem will be rebooting his cluster tonight...we shall see what happens...
I just checked.. I'm using CiscoTerm, add a CiscoTerminalObserver to that CiscoTerm to get terminal events (of course, I'm just casting the Terminal I get from my CiscoProvider.. which in turn is cast from the Provider I get from the CiscoJTAPIPeer), but a regular CallControlObserver to get call events.
Be careful with CiscoTermInServiceEv.. when you get that it doesn't actually mean the phone is up yet. I used to push data immediately after that and the data was never received.. even though there never was any error in the send process either.. the phone accepted everything but then silently discarded it instead of displaying.
I'm wondering if it would help in your case if you kept the CiscoTerm with its observers registered. One of my apps only really needs JTAPI access for a very limited time so I did try the "register, then do what needs doing, then unregister" approach and I fell flat on my face.. there were various things that didn't really work out the way they're supposed to, starting with me being unable to get any forwards even though they were set. When I changed to register phones as they are exposed to JTAPI and keeping them registered, just doing nothing whatsoever with the events that do not concern me (basically I only care about Provider events in that app.. em login/logout, new lines to a profile and phones being added/removed to jtapi control), the application started to perform as I expected it.
When it comes to http push.. I guess it's the more common way but in my own lab, that method turned out to be way more flaky than going via JTAPI... I have the apps in question running all the time and except for that one reboot, they seem to always work, whereas when I try to push something to a phone for a quick experiment, I often have to reboot the phone to make it accept the push. I don't know if there's anything wrong with my cluster but this has been my experience (and this is with a dummy auth page that always just returns AUTHORIZED)
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...