Hi there! If I have a service page shown on the phone and a call comes in and covers that page, is there a way for me to automatically bring the page to the front again? Is there a setting/configuration that I change? or do I have to specifically puch a command over(assuming I can monitor incoming calls)? Thanks a lot for your help!
As far as I know, there is no way to 'backup' and bring the page backup as easily as you might hope.
You can (and based on most user's feedback, this is probably a bad solution) set IdleURL on the phone so that the phone essentially makes requests all the time on its own to your script--as long as you map sessions, you should be able to always reconstruct the last message.
Using JTAPI to monitor the phone, and re-pushing the screen on answered incoming call is one very reliable route, although more intense than one would hope (intense on the developer, and intense on CCM resources).
I would hope you could do this without JTAPI... so in brainstorming on such a solution, the following is something I haven't done, but seems reasonable.
Let's say you now start sending the Refresh header to the phone, so then your script could contain some timer-based code which would be kicking off some special case logic in the case that the phone hasn't made a request 2 * 'refresh-seconds'. The phone is going to keep making requests unless that XML object is removed from the screen. Real world example--if the user presses the Exit softkey, or an incoming call removes this XML object, you'll stop getting requests from the phone. So then this special case code then has the task of figuring out what caused this interruption in requests, and if that condition warrants re-pushing. So I'm going to assume that the user hitting SoftKey:EXit means that you shouldn't repush to the phone, but if there is a new active call, you should re-push.
Using /CGI/CallInfo, you could determine if there is an active call on the phone. There is even a duration field here, so perhaps you could construct some logic that says 'if new call duration < 4 * refresh-seconds', re-push to phone.
I chose 4 * refresh-seconds because, in my experience, there is just alot of random delays when interacting with the phones, so best to give yourself some buffer.
Man... that's really intense. For brainstorming purpose, this approach sends a request every 2 * sec as long as the XML obj is shown, isn't that kind of heavy traffic? While for JTAPI, only one event(call connected) is sent?
You are right--it is sorta intense. It's also not very real-time--probably take 10 seconds in some situations before the screen is repushed by the application.
You sound as if you understand JTAPI--I had assumed it was a body of code you'd have to create to support it, which is no small task. If you already have a JTAPI framework to use, then I'd say go ahead. The big questions in my mind that would need to be firmly answered is 1) how many phones do you intend to scale this out to (quite honestly, I don't know how many monitored devices a cluster can support, but you can bet it's dependent on a number of factors, such as BHCA, Extension Mobility usage, model #'s of the CCM nodes, etc), and 2) Does this framework you already have, or have yet to build, have the necessary dev staff to make sure it continues to work in 4.1, 5.0, 5.1, 6.0, etc.
I like IP Phone XML solutions whenever possible because the load is almost entirely on the endpoint (other than the authenticate.asp script the phone checks against) and so simply scales better...assuming traffic isn't a problem as you pointed out :)
Honestly I'm also kind of worried about the load JTAPI would put on CCM, we have over 1,000 phones, call volume is not that high though. But since JTAPI is necessary in my case, guess we cannot dodge it. Any pointers of further reading regarding the topic? The disucssion has been very helpful and enjoyable. Thanks a lot!!
@XmlEquals: your attempts to "circumvent" JTAPI are quite interesting. Have you ever done something like that on a large scale? I only have few phones in my lab but having seen quite a few problems with simple operations such as a http post (error 6... authentication timing out even though I have a dummy auth page that just returns authorized).. I have little faith in the stability of the built-in webserver on a phone.
JTAPI, being more widely used, strikes me as the more reliable approach. It adds a hit to the CCM for sure, but you can add call event filters so that you only get the events you are really interested in and I would presume that this also limits the strain on the CCM somewhat.
To the original poster: install JTAPI on your PC.. it contains two interesting sample apps. And there's the CallerInfo sample app in the SDK. That was all I used to get started. JTAPI wise, what you're looking at here isn't too complex.
What you need to worry about though is "how does my jtapi app know there's a service on screen". Then all you watch out for is the connected event.. basically what you'd be doing is very similar to CallerInfo.. you make the push at the same position in the call flow, you just have to change the url of the service you're pushing.
@Stephen: Nope--just pulled it out of the ether. I agree with what you say--you'd have to really test it and be fully aware of some of the ugly cases before you did the XML approach. Since I didn't know what the app he's building actually does, I thought it possible that it was a low-key app and so perhaps 100% perfect behavior wouldn't be necessary.
Hi stephan, thank you very much for your comment, I'm very much interested in the call event filter you mentioned, but couldn't find a class like that in JTAPI, so how do I add such a filter?
Speaking of Cisco SDK, what do you think of the IPAddressProvider they have there? I tried but it sometime returns "null" eventhough the phone has a valide IP, or should I use JDBC to access some DB(have no idea where the DB is and how to connect to it)?
Thank you very much for your help!
I may have spoken too soon. I just searched the Cisco documentation and I only found references to filters for terminal events and there are filters for the device state server but apparently nothing for callcontrol itself. So I'd just not do anything with these events.. and come to think of it, I wonder if there's really a great overhead in the CTI manager having to filter the events (and the CTI manager is running anyway) or it just sending out everything.
As far as the IPAddressProvider goes.. I never liked it.. I never liked the asp page approach and if you browse through this forum, you'll see that its behavior can be rather flaky. CCM5 gets rid of the page and introduces means in AXL serviceability to get IP addresses.. that's where I'd focus because the ASP page isn't coming back.. in the future when we have the same CCM running on both platforms, it'll be apache/tomcat based because that's the platform that's also available in Linux - IIS isn't.
IP Addresses are nto stored in the DB, hence you can't get them. Plus starting with CCM5, direct access to the DB is blocked anyway and you have to resort to AXL to access the database (but that works just fine albeit it is most certainly somewhat more computationally complex - XML output tends to do that).
As for returning null, do those devices show up in the devicelistx.asp report in the first place? The SQL query used to look up devices contains which model types are going to be considered. Assuming you don't have the latest CCM but have some of the new generation of phones (like the 61), that report won't list those devices and consequently the IP address returned would likely be null (if there's no exception). if that is the case, you'd have to modify the SQL query in the ASP file to add the new device types. Now if you're wondering where you can get these IDs.. search the DB. Cisco has fully documented the CCM DB so if you go via the schema, it doesn't take long to find information. Here's the link: http://www.cisco.com/application/pdf/en/us/guest/products/ps6164/c1671/ccmigration_09186a008062b39b.pdf
I wanted to follow up on Stephan Steiner's comments that SNMP can be used to gather real-time info (such as IP addresses) just as easily as AXL. Having an SNMP framework, in my opinion, is a little more advantageous compared to AXL because I *assume* it's light-weight compared to AXL on the CCM (partly this is because an SNMP implementation has to query all nodes in the cluster, instead of relying solely on the publisher).
Just food for thought.
Thanks a lot for the suggestions! Somehow I cannt access the deveicelistx.asp? I have phonelist.asp though and the IP address is right there. Never tried AXL before, is it a good idea to start from the AXLProvider from SDK? Thank you very much for all your help!!!
To XmlEquals: Thanks for your comments! But I kind of assume Cisco already has a AXL built in somewhere in call manager? If that's the case, maybe it would be easier to go through AXL directly?