Hi Solo, I have posted the logs for the engineering team, I will update you when I hear back.
As for the other question related to Auto Attendant, looks like the system has 2 Auto Attendants configured - this is most probably an out of band configuration that's causing CCA to lock up. The two Auto Attendants are "autoattendant" and "autoattendant2", out of these, "autoattendant" has an active trigger (385), so I'm assuming the other one is just in there. This script has "allowExternalTransfers" set to false, so calls to any 3xx extension that's not known to CUE will be dropped. Setting this to true might help. Not sure if this the root cause, but definitely something that you should look at.
As I stated before NOTHING was done OOB everything was configured via CCA including the 2 AAs. CCA will create up to 3 AAs.
After I posted this I found the parameter "DialByExtensionAnytime" set to "false" on the AA labeled 'autoattendant' I changed that to 'true' and now have no problem 'direct dialing extensions on inbound calls. I just hadn't had time to post this correction.
The parameter "allowExternalTransfers" only applies to transfers out of the AA to an number other than an extension within the UC so this being set to false isn't a problem.
I still have the 'java.lang.NullpointerExeption' error and can't not access the UC via CCA to make any further changes.
I have also since updated my Java to the latest version and this had no effect on the java error
Can you both capture fresh set of application logs? The engineering team would like to enable CLI captures, for this please use function key F2 and F3 on the keyboard (F2 launches the console window and F3 enables CLI capture). Please note that the F3 is a toggle key, so if you hit it twice, it will disable capturing CLI, please make sure that capturing of CLI is *enabled*.
I don't need the console output, just the application logs (with the CLI capture enabled).
I am having the same issues.
I did a reset to factory last night and an complete reconfiguration using CCA 2.1. I didn't change the loaded Software Package. All configuration was done via CCA, nothing was done via CLI
I had to do it twice as the first time the config started erroring immediately due to a partial setting in the AA which I created using the Telephony Wizard. As all of the extensions weren't loaded (23 extensions) I didn't completely create some of the Hunt Groups so I left some of the AA options blank which shouldn't have been an issue.
Repeated the reset/config cycle again only this time I didn't create the AAs using the wizard. I did use the Wizard to do a basic config with only 1 phone/User. I then went back in and loaded the other 20+ users/phones via import of a csv.
- Created all the Hunt/Blast/Paging/Pickup groups.
- Completed all configuration settings
- THEN created the AAs completing all settings
After I finished the complete configuration I tested all AAs and 25 % of the extensions and everything worked great. This AM the users started noticing problems.
1. First problem noted is that any attempt to Park a call results in the call being disconnected.
2. If an incoming caller attempts to direct dial a extension (3XX) the AA disconnects as the 3 option has no action assigned. This was how it was previously configured and had no problem
I have noted that the problem appears to been somewhere in the CUE Configuration as the CCA stops 'loading' when it attempts to access the Voice Data and on the "Dashboard' it shows the CUE as inaccessible then it finally shows the VM as 0% and no CUE software version as blank.
Attempted to create the CCA TS log results in "The log file could not be created." however I am able to log in via CLI and capture show tech-support for both the IOS and the CUE Session with out problems.
I get the java error any time the CCA has / attempts to load the Voice Data from the UC
App Logs as requested.
Additional point of info I have just been informed that CUE is NOT lighting the msg notification ligth on the phones. CUE is accepting voice mail. I attempted to change "msgnotification" via my phone VM access and it states that it is disabled.
I just checked the CUE 'sh run' and it indicates:
ccn trigger http urlname msgnotifytrg
I now have corrected the java error and again have CCA Access to my UC.
I was reviewing all of the comments in this thread and noted that you only referred to one of the two auto attendants has having an active trigger (385).
I looked in the CUE Config and found that the "ccn trigger sip phonenumber 386" was missing the " application "autoattendant2"" line.
I added this line via CLI, did a write memory and was able to login via CCA.
I had logged in initially and had the failed indications. Even without logging out I refreshed and regained normal CCA Access.
I want to repeat the previous configuration was totally done via CCA so somewhere in the CCA Scripts that line is missing or ????
I have attached the App logs.
------------ text added ---------------------------
Point about the AAs
This configuration with 2 AAs is due to the fact that the end user 'closed' actions on Weekends is different than 'closed' actions during the week. This was the same configuration that was there before the 'reset to default'.
The difference was that previously the system was configured in phases.
First with a single AA then the 2nd AA was added and call flow revised.
It appears that the CCA 'fails' when trying to add both at once and TOTALLY fails if you attempt to add any AA during the Telephony Setup Wizard.
Glat to hear that the problem is now resolved. BTW, I tried this in the lab, and CCA pushed down trigger for both Auto Attendants, let us know if you can recreate this easily, if you can, we would like to look at the application log.
SOLO, were you able to capture application logs with the CLI capture enabled?