Is a basic working intercom too much to ask for?

[dharig]

I have been the disgruntled owner of a UC520 for one year now.   I have gone through five IOS upgrades and eight - yes count them 8 – CCA upgrades and still the most basic configuration of an intercom does not work.  If you are simply trying to apply a single intercom between two phones it will work.  If however you are trying to create a 7x7 grid of intercoms between seven 7975G phones it is a disaster.     It starts out innocently enough with the first few working.   After a about 15 have been added is when the gremlins come out.  Previously applied intercom assignments go missing on the phones or show up as (Unknown) users after a reload in CCA,  custom labels apply randomly and revert to default naming when using shared extensions, custom names do not apply to the phone despite showing up on CCA.   It is a complete mess.  The only fix is to go in to CLI, delete all the created ephone-dn’s and start a fresh, however, within 15 to 20 changes or saves the gremlins will come back.  I have had cisco engineers/forum moderators work with me in the past on this to no avail.  I have even had once cisco top tech really take the bull by the horns and arrange a conference call with me and the top development brass to show them how obnoxious this is.   I have worked with TAC time and time again.  Each time the TAC tech (great guys) put another completed case in their cap by methodically using CLI to build a 23 user 107 intercom matric of ephone-dn’s only to have the precious work demolished the second I open CCA and change a single config.  I have replaced the UC520, reloaded it dozens of times, upgraded each main stream release, b*tched and b*tched on this forum, waited with ever dwindling enthusiasm for each release thinking,  maybe,  just maybe, this time it will work and on and on and on.

Cisco is actively trying to make the SCBS system literally do everything but clip your toe nails in terms of features, yet they can’t make this one simple century old telephony feature work despite literally years of development in CCA.  The intercom has to be the oldest PBX feature in history.  I mean ma'Bell old.  What really ticks me off is this crazy development track they are on.  Don’t get me wrong, having the ability to pop-up a web-ex meeting request on your cisco phone at the same time it pops up in nine other locations on your digital life may be a god send to some, but for the love of the basics, STOP!!!!!  Stop development, stop making this never ending list of features that are never tested though to fruition, stop coming out with new hardware offerings for the same bug ridden management system, stop working on CUE until you fix CCA, stop wasting your technicians time on basic bugs like this.  Please,  Please, Please, Please just give me a working Intercom configuration in CCA!   PLEASE!!!!!   Escalate this to the top,  get all the necessary levels of middle managers in a room and make a commitment to just make the intercom work.  One simple bullet-proof feature in CCA that your development team can celebrate.    I mean baby-steps here cisco,  just an Intercom. Once you have mastered that, then you can put the SCBS on Mars or Pluto.   Again, baby steps!

[Steven DiStefano]

Clipping toenails I will add to the feature list :-)

But seriously, have you considered Dialable Intercom?  Most customers dont want to burn som many buttons.

One Phone, One button.  Can press the button and then dial the ext you want to intercom to (with or without mute).

Requires CCA 2.2.5 and SWP 8.0.4 <--- in the land of constant improvement, the upgrade will not be something we can avoid I am afraid....

P.S.  I am an old Ma Bell guy (1982 - 1985; NY Telephone)

[paolo bevilacqua]

I understand your frustration. I have been installing CME since few years and have quickly learnt that all Cisco GUIs are very poor quality software. Actually I knew that since some ten years before CME came out

The simple solution is that we administer all the system with CLI, teach (to some extent) clients to do the same, and they work great.

You are of course entitled to think differently, but I have found that for me and for my clients, the GUI does not add anything to the real product, that overall works very, very well.

[Steven DiStefano]

CCA 2.2.5 is the result of many months of Partner exchanges, this community (thousands of posts) and a serious direction from THE TOP at Cisco to make it work without CLI.

I will admit that previous version of CCA were lacking and I understand the frustration too.

But come home to CCA and see what you think.

[dharig]

The dialable intercom is a cool feature idea, but this is exactly what I am talking about. Cisco just elevated the game with this sweet tart feature.  When you make new features to cover up for the features that don’t work you are in a league of your own.  J     If I gather Cisco’s position correctly?  “Sorry about not making single intercoms work, but here ya go,  DIABALEINTERCOM,  Thank us later”    

PS.  I would venture to guess that ½ of all people will look at dialable intercom and think it means “disable intercom”.    When we read we don’t use phonics,  we use first and last letter recognition.  The mistake I made was just that.  “Why the heck do I want to disable my intercom”   I think a better name for this feature key would be System Intercom, Multi-Intercom, Intercom List, Intercom Menu  ect.  You get the idea!  Becouse dialable is not a word in anyones vocabulary, other than ma-bell guys,  their mind will see disable.   It's all about the user experence I guess?  Read this bellow to see what I mean.

Arocdnicg to rsceearch at Cmabrigde Uinervtisy, it deosn’t mttaer in waht oredr the ltteers in a wrod are, the olny iprmoatnt tihng is taht the frist and lsat ltteer are in the rghit pcale. The rset can be a toatl mses and you can sitll raed it wouthit pobelrm. Tihs is buseace the huamn mnid deos not raed ervey lteter by istlef, but the wrod as a wlohe.

[Steven DiStefano]

I am enjoying reading your posts and also ready that entire paragraph without thinking anything was wrong :-)

If you really want to use all the buttons for individual Intercom, we will make it work.

If you use the latest SW and it doesnt work, open a case and ping me back here and I will get it addressed.

I do remember previous Intecom problems so you are right about that, but we do not cover anything up. I think that was fixed.

Have you read the CCA 2.2.5 release notes?  ;-)  There is no cover up going on in there.

I think we got the name "Dialable" intercom from a competitor IP-PBX that saw preferred by our Partners :-)

But I agree with you.   It looks like Disable.

Steve

[dharig]

Scratch that last point.  I just enabled “Dialable Intercom” on my phone to see if that is the answer.  I get a message from my ITSP Sip trunk provider when I press the button  “This is a network announcement, please dial a 1 and then the number to place your call”

Another wonderful nonfunctional feature from Cisco CCA.  I can only imagine the TAC case needed to sort this mess out. And, by the way, putting the diaable Intercom on one phone just multiplied the issues of single intercom functionality by a measure of 10.  ,Ut, oh,  the gremlins got wet. 

Pat “THE TOP” on the back for me.   what was the quote?   “CCA 2.2.5 is the result of many months of Partner exchanges, this community (thousands of posts) and a serious direction from THE TOP at Cisco to make it work without CLI.”

Seriously,  I am sure the CCA team did work hard on this, but from 30K feet even I (a casual cisco user) can see that you are under resourced in terms of developers and testers to deliver a reliable GUI management system for the UC500 line.   My advice would be to either dig in a little deeper into the cash pockets of cisco (21 billion on hand as of today) and hire those resources or scrap the idea and just stick to your CLI laurels.   In my humble opinion your two year track record of disastrous releases with CCA has long squandered any credibility you have with a future release binge reliable so just go CLI and stop advertising the UC500 system as a GUI configurable product to schleps like me. Of course that will cut out the huge market share of schleps like me who buy this product because it is configurable via a GUI.   Hmmmmm -  Quandary.     I have not seen a single Cisco dealer or partner ever advocate or endorse the use of CCA.  They all seem to harbor the same sentiment “cisco does not do GUI, if you want to use cisco stick to CLI”.  

[dharig]

Steven,

I to can get the single intercom function to work on 23 phones by calling TAC, crying a little and letting some poor tech in India deal with my attitude on the phone for 3 hours while he painstakingly builds all the ephone-dn's and I run around the office like a chi Wawa on crack confirming all the appearances.  The issue is that one day (like today) I hire a new sales person named Kim,  sweet girl from Iowa who should do wonders for sales,  and I need to open the dreaded CCA box.  The minute I load a few changes the meticulously configured intercom buttons go haywire.   Right now sales are great, business is good and I have nothing better to do than gripe on this forum, but it is a serious aggravation to say the least.  I only put up with it because the Phones look so cool!   If you had ugly phones like Talkswitch I would dump you.  J   I jumped ship from talkswitch 1 year ago because , seriously, how pretty your phones are.  Get like 10 people in a room with a UC520 and 20 7975G phones and build yourself a convoluted intercom config via CCA.  Keep adding and changing it and you will see what I mean.  Then go to the CCA developers and tell them what happend and that a Cisco customer in Minnesota will buy them each  a case of beer of thier choice if on the next CCA release they fix this issue.   

[Anna Tsukerman]

Hi David,

I'm the product manager for CCA. I would like to understand better how we can address the problem with intercom you are seeing, and make this a better experience for you and other partners.

Let's take this off-line and I will reach out to you directly to schedule some time to talk if that's OK with you.

Sincerely,

Anna

[dharig]

I figured it out!  Cisco must have hired Stevie Wonder to do all the CCA testing.   In all seriousness,  four hours with TAC today and I am still not even crested the surface of the issues 2.2(5) has generated in my box.  Here is the recap on the day

1)      CCA can’t – I repeat CAN NOT – handle large quantities of intercom buttons because it does not track created, recreated and moved ephone-dn’s, end of discussion.  Pull that feature out until you can.

2)      When I enabled Dialable intercom per the suggestion in this thred and applied my first config to the UC520 with CCA2.2(5) a number of things happened in no particular order.

a.       My inbound SIP calls quit working because CCA applied a voice-source list to the config that blocked my ITSP Invites throwing a 500 Internal server error to them.

b.      My SNRs are all deleted from 1 sec delays and timeouts and the timeout numbers with the two cfwd-noan’s are competing and calls are not going to voicemail.   This is another systemic CCA issue.  It puts CFWD-noan durrations on both SNR and in the standard ephone config.   Or one does one, and the other does the other.   Whatever,  point is it creates another mess. CCA that is.

c.       DND is not working when pressed during an incoming call

d.      When I press the Dialable Intercom button it picks up an outgoing SIP trunk and I get their network error message.

e.      It wiped my incoming call rules out from appearing in CCA although they are still in the config when viewed with CLI

f.        I now show two licenses in my license list in CCA one for the 24 user package I bought and an extra 32 user license in my hopper.  J

g.       Am am sure there are many more issues than this.  I simply have not found them yet.

3)      What TAC found and did so far today, I have to go pick up the kids from day care.

a.       Removed voice source list 4.  Incoming calls resumed.

b.      SNR’s cfwd noans and DND are tomorrows day pissed away thanks to the hard work put in by the CCA group.

c.       The dialable intercom was not working because CCA inserts something called dial peer 1001 that has a dial pattern of *.. or some other competing pattern to that used by the dialable intercom.  That dial pattern is trumping the dialable intercom and sending the call to a SIP trunk provider.  To be honest my eyes glazed over watching TAC and hearing their explanation.  They said it was nothing I did and that CCA should not add dial peer 1001 with dial patterns that compete. TAC case 615267595 for those that want to look it up.

d.      My call rules exist and work although they are not populated in CCA.  TAC said it was some flaw in the way CCA must request the dial peer outgoing rules from the UC520 and determine which ones to populate.   Again, I was mostly glazed over at that point.  

In summary I hope that tomorrows TAC will fix the remaining issues and that the experence is shorter than four hours. Either way I will put the remaining issues to bed, comment on my experience for others to save time on and close the lid on the dreaded CCA for another spell.   Who knows maybe CCA 2.7(8) Cisco will hire Helen Keller as the senior CCA tester to help out Mr. Wonder.

I need a beer!

[Anna Tsukerman]

Hi David,

I'm glad that TAC engineer was able to assist you.

I would like to clarify that using CCA is not recommended when UC500 is initially configured in CLI. Our recommendation is to continue using CLI for this kind of deployments.

CCA is meant to be used as a configuration tool for new installations. Sometimes partners may choose to augment CCA with CLI using the Out-of-Band guide ( https://supportforums.cisco.com/docs/DOC-9809 ) for features that are not currently supported in CCA. This guide clearly explains the rules for creating configuration that can be recognized and read in by CCA.

As Steve has mentioned, CCA 2.2(5) is a result of hard work of CCA team in close collaboration with partners, users of this community, as well as the sales team that is our eyes and ears in the field. Quality was the number one priority for this release, and I feel confident that we have delivered on this goal.

I invite you to give CCA 2.2(5) a try in a new deployment and let us know what you think. We always welcome feedback from our partners.

Sincerely,

Anna

[dharig]

Anna,

I am sure you worked very hard on this, but the CCA team is either under-resourced, under-tested, under-qualified or all of the aforementioned.  I will not let you throw me under the bus as someone that is not using the system correctly as you implied.  My UC520 is a 100% CCA2.2(4) turn up and config with the only CLI commands performed done by TAC to correct mis-configurations done by the CCA 2.2(4) that rendered the system unusable. 

You may be advocating that a CCA 2.2(5) turn up is full proof, but I simply reject the notion that I need to rebuild the system from scratch because there is not an in place migration path from 2.2(4) to 2.2(5).   As with any of the previous 11 CCA releases I have been though I can tell you with absolute certainty that if I did take a day to build a CCA2.2(5) config from scratch I would hit some inevitable wall of misconfiguration that would force a TAC CLI intervention.   Then what,  CCA 2.2(6) fresh load?

I truly hate that the advertised administration system of a $40K phone system from the world’s most prestigious IP hardware vendor (Cisco) has been so dysfunctional for so long.   I would challenge you to find me any small quantity of your end users or customers that has had a positive experience with CCA and considers it a production level tool for the administration of the UC500 line.   Every thread (dozens in total) I have ever posted with regard to any CCA issues the responding Samaritans have all advised me to discontinue the use of CCA and teach my self the CLI language and administration of the UC520.  

It is not my intention to blast you or your CCA team by posting on your thread, but I truly don’t care how hard you worked on this application.  It was not enough!   I am simply trying to force Cisco to make the necessary investment in CCA to create a viable end user level configuration tool for the fantastic UC500 system.   What are my options really?  - continue to work with TAC every SINGLE time I need to make a basic change in CCA?  Look up the Minnesota state statutes on consumer protection and lemon laws to get a refund from cisco or gripe as loud as I can to the manufacture of this product so one day they produce a fully functional management application that was advertised to me in 2009 when I decided to buy this system?

P.S  Since CCA2.2(5)  my 7975G phones are re-booting by them selves every 10 minutes or so even when on a call.   The fun just does not stop with this rig!

[Anna Tsukerman]

Hi Dave,

I think the point I was trying to make didn't not come across as intended. I simply pointed out that CCA is best used for new deployment scenarios, and we have created Out-of-Band guide for the users who decided to use CLI for few features not available in CCA.

I would like to offer you a live WebEx session with me and a couple of my team members to gather your feedback and discuss the issues you have experienced with CCA. Please let me know if you would be available to spend some time with us, and I can set-up this discussion.

Sincerely,

Anna