01-12-2016 08:44 AM - edited 03-17-2019 05:27 AM
I have two Cisco ATA 186 boxes that are not registering after moving them to a different CUCM group. They're coming up rejected. Other devices in the same device pool are registering fine. If I move them to another Device Pool with the original CUCM group, they register fine.
Does anyone have any ideas on this?
Solved! Go to Solution.
01-12-2016 09:15 AM
I assume you have tried to reset the device configuration in CCM for these devices?
Also, these are existing device configurations correct, you are not trying to have them auto-register? If you are trying to let them auto register, verify that auto-registration is supported in the new CM group and that there are available DN's to auto-assign in the specified auto-registration DN pool.
If you have physical access to the ATAs you may need to reset them;
Thanks,
Ryan
(: ... Please rate useful posts ...:)
01-12-2016 09:15 AM
I assume you have tried to reset the device configuration in CCM for these devices?
Also, these are existing device configurations correct, you are not trying to have them auto-register? If you are trying to let them auto register, verify that auto-registration is supported in the new CM group and that there are available DN's to auto-assign in the specified auto-registration DN pool.
If you have physical access to the ATAs you may need to reset them;
Thanks,
Ryan
(: ... Please rate useful posts ...:)
01-12-2016 10:21 AM
Thanks for all the fast answers! It's a pre-existing setup. I also found that some 7900 phones in the pool are being rejected - showing the TFTP server as 255.255.255.255. Could this be a clue?
The devices are off-site, I suppose I'll end up manually resetting the ATAs when I can get them.
01-12-2016 09:19 PM
sounds like they are not receiving a TFTP IP through option 150 and are resorting to a broadcast to dscover tftp.
01-12-2016 10:20 PM
So a 32 bit address is definitely not a valid TFTP server.
What was the purpose in moving the device pool? Is this a logical representation of devices physically located in a new network segment? How are these devices receiving DHCP and what does the DHCP pool look like?
Thanks,
Ryan
01-12-2016 09:16 AM
I seen this before... sorry I don't remember the work around for this... Is it registering with one particular server ?
01-12-2016 09:27 AM
While I can't say this is always the cause; generally this happens when the new CM group has a different first node than the previous node. Some times, resetting the device configuration in CCM will work but often times it requires resetting the ATA itself.
Thanks,
Ryan
01-12-2016 09:17 AM
what you mean is when you changing device pool it will reject, right ?
01-12-2016 09:30 AM
I think he means device pool; which is ultimately where the CM group is applied, so I think he just referenced the CUCM group because that is where the issue is.
Thanks,
Ryan
01-12-2016 09:06 PM
Hi Raymond,
Login into ATA config page http://<ata_ip>/dev and make sure CUCM addresses (primary,secondary) are same as in the device pool CM group.
Here is a link to old but good document. http://www.cisco.com/c/en/us/support/docs/voice-unified-communications/ata-180-series-analog-telephone-adaptors/21507-ata-sccp.html#maintask1
Regards,
Sudheer Shenoy
01-20-2016 05:31 AM
Resetting the ATA was the only way. Thanks!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide