I've got CUCM 22.214.171.12400-26 and 5 ATA 187
My problem is that sometimes the ATA 187 randomly deregistered and the only solution is power off and power on the ATA.
This happen to all ATA.
I've checked if there is a new ATA firmware but there isn't.
1. please check if there is any firewall between ATA and CUCM
2. please capture the wireshark when the ATA 187 get unregistered.
FYI: we have this issue with 3 devices of ATA 187, fw 9.2(3) , the issue happened 2 times in last 4 month. During the outage the devices still repond to pings, but no HTTP and devices are unregistered. Since it's not every 20 seconds, I can't take Wireshark. No firewall between CUCM and ATA. Power off solves the issue. I enabled ssh and will wait for 3rd incident and then will call Cisco. No issues with ATA 186 reported, so it is specific to 187 adapters in a latest firmware also.
We have seen this type of behavior as well. Not deregistered but banned or something along those lines. Same resolution though...power cycle the ata to get it registered and working again. I'll see if I still have the screenshots. No firewalls between the ucm server and ata device. They are separated by an mpls wan.
Sent from Cisco Technical Support iPhone App
please check the following which might be the reason for ATA 187 unregistered,
1)We could see keep alive message from ATA-187 to CUCM but no ACK 2)CUCM sdi/sdl logs didn't receive the keep alive message and unregister it with reason 13
you better have wireshark trace to prove it and check where the packet was lost.
I will see what I can find. It did seem odd at first because we only had problems with the ATAs at the sites. Everything else was fine. After looking
at it though, the ATA 187s are SIP and all of the phones are SCCP which may bring about problems like this which we are not used to dealing with. Also, to clarlify on what we saw in CUCM, the device status was 'Rejected'. These are at remote locations registering back to HQ so it could have been a keepalive issue late at night with some telco maintenance occurring or something. I would have to look at that further. So far, we've only seen it on a handful of the devices and only once at each location. Hopefully it does not become a recurring issue.
i have exactly the same issue. i have more than 100 remote sites in which 20% is having the issue of ATA unregistered. Power booting will solve the issue but after some days will happen again. This realy annoying. i got wireshark capture before and after power booting. check attached.
ATA MAC: D0574C6BD7F1
primary CUCM: 10.70.78.112
secondary CUCM: 10.128.60.21
any suggestions please
I have exactly the same issue on a CuCM 7.1.5 cluster. All phones work fine also SIP phones. Only some ATA187 deregister sporadically an never register again. The only way to recover is to restart the ATA187 (power cycle). This must be a bug isn't it.
Any idea how to solve this?
I am having same problem here with 2xATA187 i have 3 others ATA 187 on the same site but they don't have the same problem.
I have been using ATA 186 & 188 for 3-4 years in over 10 sites and never had this problem (Other problems :) )
One of Cisco engineers advised to restart the tftp service and then restart the ATA, which fixed the problem for a while and now it happened again.
we did not reach to any solution with Cisco TAC but we did upgrade to version 126.96.36.199 and restarted the ATAs and it is working fine now (more than 20 days)
it look like it is solved by the upgrade but still customer complains from time to time that he can't send fax (giving error message)
It is a known bug. The workaround is to change the CommonPhoneProfile under Device > Device Settings > Common Phone Profile. Change anything on this. Check mark or uncheck mark and save. The ATA will then reregister. It affects all SIP devices.
Please rate if this helps.
For me it has been permanent solution so far, but if it does happen again, this is the fix/workaround.
This is what happens to the CommonConfig file according to TAC:
The normal case should be
So ATA-187 fails to parse these configuration file and keep reprovisioning as well as any other SIP devices".
I have been working with TAC for the past 3 weeks. They told me that most people are happy with the workaround. I don't like my devices going unregistered and then have to fix it. I need a permanent solution.
It has been escalated to the Business Unit and Dev team. Still waiting to hear back on what the next step is.