we despair on an issue that SIP deskphones (8845, 8865, 8831, 8832, 7841, 9951) and Jabber devices re-register to CUCM from time to time and calls abort during this event. We already working with a TAC engineer on this topic, but he also can't find the cause for the problems. Maybe someone in the community had a similiar problem?!
When a re-registration happens to a phone you can see a TCP-Timeout at the phones website. In the phone error messages you can find ReasonForOutOfService 10 and 23.
The phone looses the connection to the first CUCM node and tries to connect to the second node.
The phone registers back when the first node is reachable again. And this occurs again and again.
It should be mentioned that the phones don't re-register at the same time. The time is alwasy different.
We already performed an CUCM Update from 22.214.171.12400-11 to 126.96.36.19900-18. Couldn't solve this.
Altogether, five CUCM servers exist. One Publisher, two for call control and two for TFTP.
Then we discovered that the change of the Transport Typ in the Phone Security Profiles from TCP+UDP to UDP can solve the issue. (workaround)
After this change was distributed to all affected phones no more re-registrations happened.
Some SIP deskphones still using the 'old' Phone Security Profile with Transport Type TCP+UDP for testing.
After some time we determined when we delete the DHCP bindings of affected phones on the DHCP server and restart the phones to assign a new IP address, the re-registrations doesn't occur with the new IP.
So, we deleted the DHCP bindings of all SIP phones and assigned the Security Profile with Transport Type TCP+UDP back to the phones. (The voicegateway at each location is also the DHCP server.)
Unfortunately, after approx. a week many users reported that the re-registration issue occurs again and we decided to roll back to the other Security Profile.
We can't find the cause for the re-registration events. Our network team already verified all components and couldn't find any errors. (no packet drops, congestions and the routing works as designed,...)
It is strange that only SIP phones re-register and it only happens with Transport Type TCP+UDP. And why can the assignment of a new IP address solve the issue temporarily?
Thanks in advance for any hints and suggestions!