Potential bug in CCA 3.1

[greenturtlesteak]

I have now run into this problem twice when setting up additional phones on UC540 systems with CCA 3.1 that were initially configured using CCA 3.0.

Yesterday I was at a customer site replacing two SPA525 loaner phones with new SPA508 phones. I deleted the two SPA525 phones using CCA and created 4 new phones. After I applied the changes, 2 of the new SPA508 phones were showing up with the MAC addresses that belonged to the SPA525 phones. 2 of the SPA508 ephones were set up in IOS but didnt have any of the button configuration.

Similar thing happened the other day when setting up a new phone on our production system. Created the phone in CCA and after submitting the changes the ephone had no button configuration...Still feels like beta software.

Anyone else hit this issue?

Cole

[David Trad]

Hi Cole,

Your a genius

I just tried that now, I replaced a 525G2 with a 509G, deleted the user and created one from scratch.. CCA 3.1 either did not delete the MAC from the ephone, or that age old bug of the system retaining the MAC in memory has come back to haunt us, this may not be in fact a CCA issue but more relevant an IOS issue.

Next time, do what I just tried and it work (Does not make sense why) I changed the MAC and the phone type applied it and she worked

NOTE: Make sure the phone is disconnected before doing this other wise the MAC may not get released.

I need to add this to the Review since I was able to reproduce this... Loving the testing on this, you guys are finding bugs I have not yet found, makes life easier for me during the testing of it

Cheers,

David.

[greenturtlesteak]

Hi David,

When you changed the MAC and phone type was that in CCA or CLI?  I initially tried to just change the phone type and MAC but was unable to in CCA or CLI (dont remember what the exact error was in CLI but CCA had the MAC field grayed out) and had to get rid of the ephone all together and set a new one up.

Were you also able to reproduce the issue where the ephone shows up without any buttons configured?

Guess I'll have to do some more testing this week to see how we can avoid this in the future. I definitely appreciate the testing you are doing on your end as well. Your posts have helped me out quite a few times in the field.

Cisco should be paying partners like us to conduct this testing since there is clearly a breakdown in their testing process for these products. Don't want to get off topic on a rant though. I'll save that for the CCA 3.1 review thread.

Thanks,

Cole

[David Trad]

Hi Cole,

When you changed the MAC and phone type was that in CCA or CLI?

CCA I try and avoid CLI changes now unless there is no other option...

I initially tried to just change the phone type and MAC but was unable  to in CCA or CLI (dont remember what the exact error was in CLI but CCA  had the MAC field grayed out) and had to get rid of the ephone all  together and set a new one up. 

Yes you are right, if the phone is connected still to the system and registered it will remain grayed out, you must make sure it is disconnected and then you can make the change... Well at least that is how it is working for me and have used it more than once to do it

Were you also able to reproduce the issue where the ephone shows up without any buttons configured?

No this means that the phone has auto registered but no ephone allocation, which I must say is quite odd to be honest, because Auto Registration would give it a number most likely outside of the range you are using unless you are using the default range CCA has issued during the Telephony Wizard.

Guess I'll have to do some more testing this week to see how we can  avoid this in the future. I definitely appreciate the testing you are  doing on your end as well. Your posts have helped me out quite a few  times in the field.

Its a two way street, I take just as much as I give, I am quite useless at data routing/engineering, but am quite handy with Voice engineering, so I tend to linger around the data forums to lift up my skill sets (Not working as well as I would have liked it to).

Cisco should be paying partners like us to conduct this testing since  there is clearly a breakdown in their testing process for these  products. Don't want to get off topic on a rant though. I'll save that  for the CCA 3.1 review thread.

I keep saying it and most likely will continue to keep saying it.. Never have I ever in my entire life seen anything developed within a staging or development (R&D) Environment ever work as it is intended too, it simply does not replicate what actually happens out there, and thus there is a reliance on Partners to help steer the way the product should be developed and dare I say enhanced... It is up to Partners like all of us on here (And customers alike who post as well) to make sure Cisco keep in line with what the market is doing and the direction it is taking, we are the cold face of dealing with the customers, and that is how it should stay in my opinion, we are good at what we do, Cisco is good at what they do (Build awesome kit).

The review thread is a pedastool for all, not just a voice box for me, it was created so everyone can share their own review, this is what will make the next release of CCA even better if it is kept within the spirit of the thread

Cheers,

David.