Bug found with CCA 3.1.1 DID Mapping

[David Trad]

Hi Cisco Team,

I did report this a couple of times already as a newly introduced bug with CCA 3.1.X this was not an identified bug in version 3.0 and has only just recently surfaced.

The Issue:

• DID mapping when using 100# in-dial ranges either on a BRI or PRI based system
• Unable to make modifications to an existing mapped range, especially worse when configured with a pervious version of CCA
• In order to make changes you have to delete the mapping and create individual maps, you cannot do ranges it just errors out and says that the range does not match the extension range being used
• If we roll back to CCA 3.0 changes can be made with ease
• Creating the rules during the TSW is not a problem, only when wanting to modify it after the fact
• CLI modifications in accordance with the way CCA builds the config does not rectify the situation, CCA refuses to refresh its information from when it first parsed the configuration, even after you have made changes using teh GUI it reverts back to the original build ?????
• Tested on multiple systems, all produce the same results

An interesting thing to note with the above, If I build say a 50 line translation profile/rule system it works, but if you open this up on another system that has a fresh install of CCA 3.1.1 it locks CCA up and CCA has a massive memory leak and spikes up to a little over 900mb in memory usage, this was able to be replicated on two systems, the poor netbook just crashes as it runs out of RAM... LOL I thought this issue was restricted to managing builds that were done with CCA 3.0 but it would seem this problem is producible on a fresh 3.1.1 install, still working on verifying this and recording it as well.

Work Around:

Make the required configuration on the CLI following the design flow that CCA uses, whilst it will work CCA will not recognize the configuration, even when it modifies it itself, but if you roll back to version 3.0 it is recognized and you can modify it then using the GUI.

Its nature is a problematic one, which ever way you look at it the management side of this is a nightmare and has a massive downside to it, the issue is reproducible on multiple sites as our target space of late has been to sell the UC-500 series with 100 number in-dials either on BRI or PRI circuits, it gives us a selling edge given how much can be done when you have this type of flex, but this problem pretty much destroys the majority of that flexibility... Which I am sure can be appreciated.

I do have a screen recording of this problem, but sadly this is recorded using TeamViewer and not WebEx so unles syou have TeamViewer to play back the recording, there is no sense in my uploading it... But this should not prevent Cisco from looking into this and identifying the issue internally. 

Cheers,

David.

[lgaughan]

Hi David,

Did you get the CCA troubleshooting log on this one?  And any recording you have is fine (TeamViewer is freeware).  This will allow us to get a good idea what is happening on the UI and your errors.  Otherwise, we risk finding problems when reproducing your case, but not exactly the problems you experienced. 

Thanks,

Laura

[David Trad]

Hi Laura,

I don't have any of the debug info as I had to do it via a TeamViewer session to the clients computer, and once the bulk of the work was done that system was decommissioned as they try to find me another suitable way of managing the system remotely.

Attached is the TeamViewer recording, which does not display much but I hope it gives you some indication as to the problem that is happening.

I will however make note of the fact I need to capture these logs, it is a habit I have not got myself into yet and I should **Smacks myself on the hand for it**

I will try and produce a log for you when they ask me to update the DID mapping, which no doubt will be soon, as I think they have not made me shed enough hair yet

Cheers,

David.

[focusonit]

I too have a simialr issue that has appeared on a system.

A system configured PURELY with CCA 3.2

Created an in-dial on all BRI port to map the first 80 number to extensions in one rule.

I have a running config of the system after this and all was OK and all items showed up ok.

Something happened and now the CCA doesnt show ANY in-dial mapping however they are still there in the running config. In the config the rules now skip every 10-20 item and then they are added at the end.

ie

rule 13

9999 9900 / 300

x

9999 9909 / 309

rule 14

9999 9920 / 320

x

9999 9929 / 329

rule 15

9999 9940 / 340

x

9999 9949 / 349

xxx

rule (lets say about 20) - then fills in the missing bits EXCEPT - see below

9999 9930 / 330

x

9999 9939 / 339

EXCEPT indial 9999 9910 - 9999919

Any ideas how to force add the  9999 9910 - 9999919 range or what do I need to delete to enable the pruging and fixing of CCA?

[David Trad]

Sorry Tim

I wish I had some good news for you but I don't, if the problem was not

resolved in 3.2 then the same issue still exists.

Here is the catch, although CCA created the translation rules/profiles and

the associated connections to the dial-peers, it only takes one little

stuff up from CCA when it is writing the config for the translation config,

and BINGO! The whole thing has gone the way of the dodo bird, and the only

way to fix this is to delete the translation profile and force CCA to

recreate them from scratch... Not a practice you want to do on every system

that goes this way.

By the way, Cisco were fully aware of this issue and I documented the

daylight out of it, I never actually got a resolution to this problem I

just found ways to work around the issue, albeit very annoying to have to.

Cheers,

David Trad

"Sent from my Acer Iconia A500"

On May 30, 2012 8:19 PM, "focusonit" <

[focusonit]

How can I delete the entire in-dial rules (Assuming from CLI) so that CCA can recreate them?

The rules are really simple 1-1 mapping + 2 conference in dial extensions.

Regards,

Tim Austin-Mills

IT Engineer

Focus Communications

Phone: 03 8788 3710

Fax: 1800 600 999

Call us today about Telstra’s new 4G network – Australia’s fastest mobile broadband:

[David Trad]

Tim,

This could be a pain :-\

Try first deleting the site from CCA and recreate it, hoping that CCA

doesn't retain existing information and rescans the whole system and is

able to pickup the configuration...

Crossing my fingers that this may also help you out, the other way is a

real pain and even harder to explain on a forum.

Let's cross that bridge only if we have to.

Cheers,

David Trad

"Sent from my Acer Iconia A500"

On May 30, 2012 8:45 PM, "focusonit" <

[focusonit]

No luck with creating a new site.

I had a great Cisco engineer help out - looks like it wasnt the first dialplan they had seen messed up

He quickly deleted all the mappings via CLI and then we were good to use CCA again

[David Trad]

Hi Tim,

I'm stoked that you managed to get support staff to help you out,

especially on the CLI side of things, that is not always something everyone

gets.

To be honest with you I was so no looking forward to having to explain how

to fix this up via CLI, I was just going to organise a time to remote in

and work on it with you.

Unfortunately this is a regular occurrence, so after awhile you get used to

working out what to do... But I'm happy that you are all sorted now

Cheers,

David Trad

"Sent from my Acer Iconia A500"

On Jun 1, 2012 12:42 PM, "focusonit" <

[Scott Martin]

I've had this issue also, and have found that just doing a one-to-one mapping of a single extension to a single indial during the CCA startup wizard, then going in to the incoming dial plan, hacking it all out and starting again.

I tried to do it the CCA way with 100 number indial, and had the same issue - it crashed the application and you have to start the wizard again from scratch.

Regarding the CCA config, just make sure you hit Apply or OK after you do anything. It doesn't seem to like being told to remove some CLI and add some CLI in the same process.

Cheers,

Scott

[David Trad]

Hi Scott,

Next time you are working on this, try and do something for me you will be surprised what you see happen..

Press the "F2" key and bring up the debugging dialogue, watch what CCA does when you try to modify the DID mapping.

No matter how many times I tried to get Cisco Support to understand this they just wouldn't listen it was like it the problem didn't exist and it was something I was doing wrong

So in the end i decided to take the matter in my own hands, wiping out the DID mapping manually via CLI time and time again, I almost perfected it as an art so that way SBSC would never have known I made CLI changes, practicing on my LAB system until I got it right, then fixing up multiple deployments effected with this problem after hours in my own time so the customer was not adversely effected.

Understand though, whilst I criticize Cisco heavily on many things, I still love the products they make, what I call into question is the many silly decisions they arrive at by someone who must not really understand the market or doesn't realize that there are other markets out there outside of the USA, or they just stopped listening to their partners and get a feel from them of what needs to be done, and this was one of Cisco's strong points over their competitors and over the last 2 years that just dwindled away.

Ringing SBSC and getting denied support on such small trivial issues because of not being Express UC certified and which was directly attributed to a problem created by them and their software, was the straw that broke the camels back for me...  Even though when I escalated it, it was just fortunate that someone recognized me from these forums and was kind enough to approve CLI changes, but that made me stop and think, what about others who are suffering the same fate, it was this one problem that kicked of a chain of events for me.

Cheers,

David.