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.

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

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”.  

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

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!

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

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!

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