This UC520 is REALLY frustration the integrator and the customer. There have been MANY "quirks" that make the quality look bad. One such quirk that is totally frustratiing and reproduceable is when we make changes to lines on the 509 G phones. If we take an extension (lets say 10) and move it to line 1 then co_line 1 to slot 2 with a label of the telephone number I.E (203-229-2435) and assign it an owner, Hit OK and it comes back configuration sucessfully sent to the uc520. The phone reloads and comes back with wrong labels, lines in the wrong place and labels that we didn't even type. It is EXTREMELY FRUSTRATING.
Another thing we do is assign CO Lines to buttons... It I assign CO_line 1 to Button 5
CO_LINE 2 To Button 6
CO_LINE 3 to button 7
I get random results when the phone reloads. Sometimes I get CO_line 1 as 0/1/0
Sometimes it comes back as 0/1/2 and sometimes 0/1/3.
The randomeness is infuriating.... I check the config via the CLI and it looks correct, but the phone shows the wrong lines in the wrong places with the wrong labels...
Has anyone seen behavior like this?
I have tried various machines running CCA with various revisions of Java all with the same results.
ANY help is appreciated
In the latest CCA 3.1.1 which I ust downgraded due to weirdness... I was assigning optins to Autoattendant and the heading was users and it display only BLAST groups... and when I went to BLAST Groups it showed only USER NAMES... weird...
I had to go back and forth 3 or 4 times and then the views refreshed and worked properly. It is very frustrating.. Also the wait for the READING and WRITING of the CCA to the UC500... Too long.
This is a common problem and has been one of my complaints, and sadly does still happen from time-to-time on 3.1.1
There is no great fix it solution for this, other than to ext CCA and then reconnect, this should purge any information it is housing in cache/memory and display the correct configuration of the system when it parses it, CCA is pretty bad an retaining information of changes it has made and then reflecting those changes correct to the user.
To avoid a lot of problem try and change one thing at a time, multiple changes in some cases will yield unwanted results, or it does not even get applied to the system.
If the problem persists, then I highly recommend you delete the button configuration on the system, reload the phones (Don't just to a refresh/restart) and then go through and reapply the configuration, the soft/quick reset that is done does not always reflect the request changes.
Hi David, Thanks for the reply..
This is More than an irritation. This has the customer ready to throw us out. Partner was there yesterday simply to move lines around on the phone. 4 Hours later not one phone was laid out correctly. Each change you would make would change something else on another CO line. My favorite is it would randomly change the associated port... All of a sudden line 1 became line 2 etc. After 4 Hours the phones are a mess.
Does anyone know if this is a Priority 1 with the BU?
Could you imagine if we got this behavior on a router like an ISR?? Why do we accept it here?
(Just a question and pardon my frustration)
I will attempt to do it one change at a time with a reload of cca between changes..
Or better yet, Maybe just the CLI
Thank you David!!!
Hi Paul. I cannot really add anything to what you have said, other than I have had CCA screw up my button assignments on a UC560 with SPA508 and SPA525G phones in the past. I would like to say, however regarding your previous post, hallelujah. As a customer instead of a Partner/Reseller, I have gone through all these frustrations firsthand, to the point I was almost ready to throw it out as well. CCA as a tool is still far too unreliable IMHO, and while I don't wish trouble on anybody, I'm glad a Cisco employee is seeing just firsthand how frustrating it can be.
Given that there is not a lot of complaints about this, so far the only ones I am aware of that have experienced this issue and more than once is Myself and Bill (Previous Post), and now You...
I would be more then willing to join a WebEx session with you, if you can arrange a time that would not have me up to an ungodly hour, and would love to go over this with you and look at the machine, firstly to have a quick look at what CCA is doing when you apply a configuration and secondly to resolve it for you quick smart.
FYI... I am in Australia, so keep that in mind when you work out the time zone and in a +10 time zone.
Happy to help you out if you would like that type of assistance..
(PS) I agree with you whole heartedly regarding the ISR and the UC-500 comparison issues, but keep in mind whilst fundamentally they are almost identical units, the UC's do have different setups in the back ground of the IOS if I am not mistaken, and CCA looks to manage the system in consistent manner and I guess from Cisco's perspective, cleaner manner (Which I have no always agreed with). ISR are predominantly configured via CLI unless you are a CCP 2.5 user and do your builds using that, CLI gives us a greater level of control, but has a much loose degree of consistency.
David / Bill,
We have filed a bug to track this issue.Here is the Bug ID: CSCts28637
It may take a while for this to get resolved. Thanks for your feedback.
I am still seeing this trouble every day and getting complaints from the field. I witnessed it first hand with a partner again yesterday. It seems as if we simply can't put a co-line on a phone which means we simply can't use hybrid mode. This is totally unacceptable to the partners. I have checked with the owner of the DDTS at Cisco and await an answer. In the mean time Has anyone found an alternative to this?
I didn't say this so it must stay between the two of us right??
When making your changes I.E CO-Lines etc..etc.. And they don't come up on the phone right, do a couple of things to see what silly business CCA is doing, such as hit the F2 key watch what it does in the debugging console, then match that up to the CLI out-put dialogue that pops up once it has finishing writing the configuration.
This is always a huge hint to where CCA has gone wrong...
Then quickly duck into CLI and make the changes yourself with CCA fully shut down, then if you load CCA back up it should refresh its configuration when it scans the config and things should be back to normal.
The slow way to do it is to apply one change, then click refresh so CCA get a whole new "show run" and then apply the next one and refresh it again... Very painful and the frustration may cause you to do unnatural things to the system, so maybe avoid this method unless absolutely desperate or if there is no other way to do it.
I have only recently started to get a good understanding of how CCA manages the system, I find it very odd as the logic behind it does not really make much sense, when we designed a configuration tool using PEARL it was much simpler and had better error correction/control, it would have been good if we continued in its development but would have been too hard to keep it up to date with all the CCA style setup, all the configuration changes were made based upon how we would configure a system, where as CCA looks at one particular methodology (And rightly so).
Said it 100 times already and will say it again, this should be an on system configuration tool (Web GUI based) and run of the Flash Card, using scripting to configure and manage the system, computer systems have far too many things surrounding them that could cause one much grief, and I wish they seen this when they were discussing their development cycle, I honestly think they ignored the signs and didn't look at the path that all their competitors including the open source community went down.
I spoke personally to the owner of the bug. I questioned why it is a sev 3 and didnt get much of a response other than it will be fixed in CCA 3.2.
Here's hoping it will be.
Hmmm what to say... OUCH!!!
That is not a response I would have taken to easily, and knowing myself pretty well would have spat the dummy over it
This issue can cause some major grief and shouldn't be in the wild, but leaving it till CCA 3.2 is a bad mistake since that is still a little way off.
Anyway's good luck with it, I am going on Hiatus again and wont have to work with another UC again for a little while