We have upgraded CUCM from version 4.1 to version 6.1. The upgrade was done successfully.
After the upgrade , of the CUCMwe wanted to make an upgrade of the ATAs firmware.
We have uploaded the firmware (3.2(4)) successfully on the CallManager cluster. The issue is that the ATAs did not upgrade their firmware!
we have restarted the tftp server on the callmanager server, we even restarted the whole cluster but still the issue persists!
It's the first time that i see such issue.
Can you please give me an idea about this issue and how could be resolved?
Thanks in advance.
Open CUCM admin page and go to: device > device settings > device defaults and update ATA software information there. Soft should be in same place we CUCM stores default software.
Pls, rate if this help.
I have checked and the new firmware is already where CUCM stores the default software!
Any other suggestions Plz?
You can check the atadefault.cnf.xml file, this the file where the configuration of the ATA is store.
There you can specify the firmware that the ATAs are going to use when boots up.
Also you can check if in the device defaults in the CUCM administrator this firmware is list there.
CCNA, CCNA Voice
Thx for the advice, checking tje atadefault.cnf.xml sound a good idea!! Can you please tell me where i can find this file?
Thank you in advance.
This file should be store in that FTFP server where the ip phones gets the configuration.
If the CUCM is the tftp server, you can go to OS administration and there in TFTP.
Yes I am using the CUCM as a TFTP server. I have gone to OS Administration > TFT Management > Find , but unfortunateley I did not find the file that you mentioned!!
And in this section I cannot modify any of the other files that I have found!
I am sorry, Can you please explain further? How should i use the comand get ?
With the OS admin page I only get the following file concerning ATA: ATA030203SCCP051201A.zup
Hi I am sorry, iwas mistaken, in the OS administration I found two files.
Should i delete the ATA030203SCCP051201A.zup file? inorder to force the ATAs to get the new firmware?
Thanks in advance.
Hi, are you sure that the only way is to delete this the ATA030203SCCP051201A.zup from the TFTP?
After deleting this file, and for exemple if there was a power failure, does ATAs still work fine?
I deleted the ATA030203SCCP051201A.zup from that TFTP, but unfortunateley nothing changed !! the ATAs did not upgrade after the reset !! It's really strange. Do you have any other suggestions?
Thanks for ur help in advance.
We have a CUCM 220.127.116.110-13 CLuster:
- 1 Publisher (IP 172.29.0.1)
- 2 Subscribers (IP 172.29.0.2 & 172.29.0.3)
I have made a wireshark capture, after deleting the old firmwatr file (*.zup) from the TFTP server and reset the ATA.
Please find attached the traces.
The IP address of the ATA (in the Wireshark traces) is 172.29.1.195.
The CCM TFTP Server IP address is 172.29.0.1
Thanks in advance.
It appears that ATA 3.2(4) does not like CUCM 6.1. I have upgraded my ATAs to 3.2.3, which is compatible with 6.1 and they work a lot more reliably with fax passthrough. I still have a TAC case open on this so will post again if a resolution is possible on 3.2.4.
I was able to upgrade to Version 3.2.4. I used the Phone based Method.
1. Download the ZIP File for 3.2.4 SCCP.
2. Run sata186us.exe -h<
3. Attach a Phone to the ATA on Port 1. Follow the Steps printed on the console during lauch of sata186us.exe in Step 2.
Did anyone manage to find out why tftp upgrades from callmanager didn,t work. I have the same problem and i can't use the sata186 method as all sites are remote..?
This is bug in the CUCM, what you can do is create a new CUCM group and one DP add all the ATAs there and do the firmware upgrade.
Thanks for that Info. Can you tell us in which version this bug will be fixed or at least the bug ID if it is public ?
Hi, can you tell me how this helps the ATA code upgrade? I have the same problem and want to upgrade the code on my ATAs.
What does the new CUCM group and Device Pool do to help?
The new CUCM group and the device pool is one of the work arrounds that we have in order to fix the issue. Also you could try to use and external TFTP server for this or upgrade the code manually, or finally follow the process that is listed under the bug description.