Hi Cisco Team,
Would like to bring to the attention of the Cisco Dev's the following issues that are somewhat disturbing and worrying, they have been noticed in particular of the last two larger deployments using UC-560 systems, they are continual and require some further investigating.
Some of these issues may seem like nothing, but I do believe they have a larger implication to the system functioning correctly. Please be aware this will be quite long as it has been an ongoing investigation for a little over 2 months now, SBCS has not been involved as of yet with all the issues only on the most pressing ones (Complicated story as to why).
System Outline:
- Cisco UC-560
- Fractional PRI
- Latest Software Pack
- Incoming Calls go to a receptionist Blast Group (3X Reception Phones)
- 1X SPA-525G2 with 2X SPA-500s Modules & 2X SPA-508G's for Reception Phones
- 4X Park Slots on the system used to hold and manage incoming calls (Due to the SPA phones not support Octo-Line)
- 50X Desk Phones 49 of them SPA-508G's
- 1X Cisco ESW-520-24P & 1X Cisco ESW-502-48P (Updated to the latest SW)
- 100 In-Dial Range, some direct to extensions (Managed and created by CCA) and others to a blast group
First Issue:
- Management of users using CCA & Configurations just disappearing -
When using CCA to manage the users, a phones/users configuration may be deleted, further to that other phones/users configuration may be deleted when you never even made a change to that phone/user, for instance when making a change to the button layout of 45 of the phones (Which takes a loooooooooong time) 9 of the phones had random configuration removed such as the phone type, button configuration, and a mumble jumbled MAC Address, somehow or another CCA managed to change all that, the only way to reinstate the information correct without put the system in a state of non-use was to do it via CLI, then CCA would recognize the phones again.
The issue is random, but the pattern is distinct, it happens predominantly when making bulk changes, once you reach over 10 users the issue starts to surface and the phones that get effected are random, there is no distinct correlation between the settings update and the effected phones, even the dialogue box that appears and shows what commands where made comes up with just two lines, the DN that was modified and and exit, no other commands issued.
- Configuration update and loss of information -
When making basic updates to the configuration such as adding a park slot, or updating a Blast group, or even changing a users details, the system would randomly drop configuration changes that were previously saved, or the update would not complete even tho the dialogue box said it completed successfully and shows you what commands where sent to the system. None of this is explainable, I really cannot narrow down on the problem, other than when working intensely in CCA and for long periods of time, in Task Manager CCA can reach up to 680MB of RAM usage, and it starts to slow down... I'm thinking there is a memory leak in the Java code, this only happens when you are in CCA for long periods of time, say over two hours (Which is not uncommon with larger deployments BTW).
Second Issue:
- Phones Not Behaving as they should -
Recently it has been noted that phones are randomly placing their own call forwards and sometimes to an unknown number, typically if it is user error you will see a recognized number, either an extension of a user or a park slot, but in 80% of the cases it was to a random number and usually 8-12 characters in length, its quite mind blowing actually when you see it, kind of makes you laugh when you are investigating it and the client is not looking over your shoulder. There is no way in CCA to remove this call forward, and the phone itself does not show that there is a perm call forward in place, it just thinks that its business as usual, you although OM at times can see it but normally CLI is required to remove it (This was tops the insane chart).
- Park Slots not functioning as they should -
The users are taught two ways to place a call on park, that is using the transfer soft-key method and or just pressing the park slot. This works as intended, it is what happens next that is not ordinary, basically at random times no user is able to resume that park slot, the caller just hears an MOH music that sounds like a broken record, constantly looping on itself for about 4-6 seconds and then resuming the MOH from the start again, and then shortly after an engaged signal... However this behavior is random and hard to predict, but a reload of the UC-560 seems to remove this issue for about half the day and then it starts to slowly surface again, with a reasonable progression in miss rates.
Sometimes this problem is not propagated to the other park slots (all sites have been tested for this theory) but after general use that park slot tends to become infected with this aggressive problem. Again I must point out that this is randomness at its best and finest form, because a good portion of the time the issue does not ocurr, it took two hours of watching the receptionist and other users in action to see it come into play, and then from nowhere for it to stop happening, and I know the users where doing the right thing because I was watching them during the process.
Third Issue:
- Office Manager having its own set of issues -
I have been training the receptionist and office administrators on the usage of OM, however some bigger challengers are being thrown at us and there is no way to address them, for starters it can take up too 15 minutes for OM to load up and read the configuration (Mainly sticks at the CUE part), after 15 minutes it times out, but if you try again immediately it may do it in 2-3 minutes. When applying changes it will take up to 10 minutes to apply the change or just time out with an error, but if you check the configuration on the CLI it partially applied it (WTH????), if you move on and click the discard button to saving the changes, the partial configuration remains on the system, but the next update can happen in under 2 minutes... And I must point out that these are simple changes such as forwarding calls, password changes and name updates, trivial tasks that should be done with ease.
OM Also at times displays a phone as not in service, but when you walk to that phone and use it, it is in service, it is registered and can make/receive calls etc..etc.. This gives the receptionist/administrators grief as they think something is wrong so they are constantly checking these phones... This needs some looking into, and I point out not at one single site and predominantly only with the larger deployments (15>)
Fourth Issue:
- UC-560 showing unusual behavior issues (May relate to CCA not to sure) -
If I program the system with Blast Groups or direct calling, then the client changes their mind and asks for some Park Slots, I program them into the system using CCA (As one should), This all looks good and sweet, until you try to use them and configure them to a button on the phone, either the phones do not take the configuration, or the Park Slot does not work until you reload the system (MUST write mem before you do so). CCA Says it reset the phone, it appears it has as the screen refreshes and the buttons show up, but still you cannot use the function until the system is reloaded, this also happens with speed dials (Never once have I seen this).
Again I must point out that it seems to be on larger deployments, in the LAB setup we have 6 phones and I cannot replicate this one particular issue, and outs is a UC-560 so I am not sure if I can put this down to a UC-560 Issue at this stage (Although these problems appear to be happening on them)
- Phones Randomly Locking up and becoming unresponsive -
This one is a really odd issue and again no explanation can be found for it, basically the phone looks alive, the click still keeps ticking, it is showing up as registered on the CME, but it will not ring (Just goes straight to busy tone even if VM is enabled) and you cannot make a call, sometimes unplugging it waiting 5 seconds and then plugging it back in brings it back to life, but I have had to at times reload the whole system to get it to work again, this seems to happen so far on the SPA-508's and SPA-509 phones, have not sold much of the others to see it happen with them yet, and this is completly random and never the same phone in the same day (Yes that part is unexplainable to me) and on more than one system (again on UC-560 systems).
Fith Issue:
- SPA Phones having bad audio quality -
Now on more than one deployment (3 now and counting) the clients are complaining that side (B) is unable to hear them properly, at first this was mainly coming from those who were using analogue (FXO) lines, but now this is migrating to PRI based services, not as much admittedly, but still happening none-the-less, this is a bad sign and is going to come crashing down like a house of cards, we sell the Cisco SPA phones with our hearts on our hands as them being high quality, but yet in all actions including replacing 15 of them at one site, the problem will not abate There is something fundamentally flawed with this phones and are reminiscent of the SPA-942 phones when I sold them with Asterisk systems, we had to plain with all sorts of gain settings to get something decent audio out of them, in the end I just went back to SNOM or AATRA phones, I cannot do that this time and cannot even work out a solution of upgrading the phones to 7900 series (Again out of our hands as the systems are sold under our National Carrier), one simple question with a BS answer "ARE THESE PHONES UP TO THE TASK AND ARE OF HIGH QUALITY???" I just want honesty and a straight answer on this, because the concern now is getting very very very deep and being a fan boy of Cisco for so long it is really knocking my confidence about a fair bit selling this... what ever it is!!!!
There are a host of other issue including that of CDR records, SCC, simple system management, but right now I am emotionally and mentally drained, plus my hands are getting really sore from typing non-stop since I come into work putting out fires, I cannot remember ever being so exhausted working with Cisco System, yeah sure they gave you problems but they were easily fixed with a simple call to TAC, Now when I call SBCS I get people on the phone either cannot speak fluent English or understand me, ask me to do stupid things which are of no relevance to the issue at hand, or cannot merry up the support contract on a device to the UC system because of what ever arrangement is in place between our national carrier and Cisco, the headache is so huge what ever margins are made on selling the things is gobbled up just in managing the clients issues and trying to work through the lack of SBCS support (Not taking shots at the guys because they are only doing their jobs, simple, and I have no animosity towards them what-so-ever).
I could understand and appreciate if this issue was happening on a single system, but when the issues start to surface on more then one system, and many hours are spend looking at if the problem falls squarely with what I am doing, I am left with limited options, I have even tried to side-step SBCS all together by trying to wean some basic support from Dave Harper when I clearly know I shouldn't because desperation sets in to just clear this problem out, which again yields its own problems, because I am now making someone else accountable for the issue when it clearly is not in their domain
HELP!!!
Please take this rant with all seriousness, I am not asking for an army of support but just someone who is in the know to look at the problems, on all fronts I.E CCA/OM/UC-500 as each one will require their own set of expertise. I have worked on UC's and Deployed enough of them in the last 3 years to have hit every issue, but the most recent ones just linger around like a bad smell.
Cheers,
David.
Cheers,
David Trad.
**When you rate a persons post, you are indicating a thank you or that it helped, but at the same time you are also helping to maintain the community spirit - You don't have to rate posts and you wont be looked down upon :) *
