Hmm, my reply on Friday must not have made it through. I was just wondering if using the priority tag in the CiscoIPPhoneExecute was not enough.. using priority 2, only phones that are not already off-hook would actually execute the command.

Dang...that's a good method...and it would've worked beautifully for this last install because they only had 40s and 60s...if I hear back that they're experiencing delay issues, Stephan, then I'll definitely try it!

My only concern in the future would be if 7912s or 20s get into the mix...

DB

The priority tag is a good method except the phones do not support priority tags on URI's only URL's.

So if you want to use the priority tag you must issue a URL with a priority and then the URL must return the uri RTPRx etc....

In the next firmware release for the 7912 (6.1) you will see a number of bug fixes related to this problem. Prior to 6.1 you will see the browser window open on the phones and sit at the requesting state. This is also true of the IP Communicator.

Regards,

Ian Pitts

Syn-Apps

Whoops...I wish I would've read Ian's response more carefully last week...here's my saga so far:

Our client is paging 80 phones. So 1 phone initiates, 80 phones listen.

The delay time that it takes to get every phone listening is well over 10 seconds...far too long for a page...so thus begins my adventure in cutting down the time...

I switched to just using the priority tag which should cut down the number of http requests by half, and it's still taking around 13 seconds. (and this morning I had to change back to my old method because I just realized what Ian said about URIs not working with priorities.)

I thought maybe modifying the authenticate.asp file to return "AUTHORIZED" on a certain user id without running the rest of the script might speed up things, but it really doesn't...authenticate.asp returns pretty quickly as it is.

I just realized this morning I'm doing something stupid by using HttpURLConnection.getInputStream even when I don't need a response.

Other than that, I am just using a generic for-loop to traverse through the idle IPs and send them each a push...would I gain anything by using threads instead?

One of the engineers here is pushing on me to learn JTAPI instead of using the Cisco XML objects and http requests through java and Tomcat (he's never used JTAPI, but has somehow embraced it as all of the answers to our problems).

Would I actually see a performance boost from JTAPI that would make multicasting 80 phones on par with a traditional paging system?

Two problems are plaguing this application: speed, and knowing when a phone goes off hook (the tag on StreamingStatisticsX only goes "Active" when a phone is in a call...if it's still in the dialing process, it's considered inactive)

If anyone can give me any encouraging words about JTAPI or what not, or if it's possible to achieve 80 phones listening to a multicast in under 3 seconds, it would be much appreciated!

DB

Do you know where the time is being spent? If you can narrow down where the timesink is, it'll be easier to fix.

Are you still checking the status via the RowStatus? If so, is that consuming your time? If you just do the push regardless of busy status (and don't perform the check), does that speed it up?

Are you still doing a HttpURLConnection.getInputStream for each push? If you don't need the response anyway, you're better off without it. In any case, the call to getInputStream may be blocking until it receives the response, which would add up over pushes to 80 phones (ie its the response time that slowing down the loop). Stop waiting for responses and see if that speed things up.

Jtapi would be faster in that if you're observing all the phones you can quickly get the status, and you could use the sendData terminal function to push the xml. That said, you may not need Jtapi for what you're doing here, I'd try and identify where the time is being spent first, before beginning implementation of a jtapi solution.

Maybe some logging would help in profiling as well (ie log4j). Many options!

I guess it depends on where the time is spent of JTAPI or threading would be of any use.

On the up side, using JTAPI you can reliably find out if a phone is off hook or not, and the sendData method ought to be more reliable because the server is directly sending to the phones. If you look around this forum you'll notice that every now and then there are inexplicable problems with HTTP posts to phones, and which require at least a phone reboot.

though JTAPI is definitely not the solution for every problem ;)For instance Cisco didn't implement all of JTAPI 1.2, and Sun is up to JTAPI 1.4 in the meantime..

"In any case, the call to getInputStream may be blocking until it receives the response"

Ahh! Good job Aaron! That was it exactly. On phones like 7940s and 60s it was taking approx. 200~300ms for the call and response (900ms on 7912s) and it was stacking up...

I implemented threading so all the phones are polled and opened at the same time...In a test of 7 phones I'm seeing the last thread slide out to 380ms (I'm also running on a 500mhz Celeron processor for my test server, so I expect better performance from the customer's server)

I'll be updating their system again tonight.

Thank you Aaron and Stephen for your comments!

DB

Happy ending to the story, with exception handling:

On average the last of the 81 phones is coming back between 420~580ms

I set a one second delay to occur to the Originating phone so it displays a message and starts the multicast after the phones have connected.

One horrible thing we discovered: after the paging system would run for a few, the IIS service on Call Manager would go down. I added a few lines of code at the top of the authenticate.asp page to always authorize the paging user and return, and we haven't seen the IIS service come down since.

I believe there's a race condition happening in the ActiveX object that authenticate.asp uses...I just wanted to toss this out there in case anyone else tries authenticating 80+ phones at the same time....