Hi Ian,
If you are using third generation phone(7970, 79x1, 79x2, 79x5), then there is no fix for it.
This is what I got latest update.
There are a couple of things that need to be kept in mind:
1. Phones will unregister from the CUCM and register to the SRST GW
2. GW will tear down Q.931 backhauling from CUCM and will function as a standalone call agent.
The phones will lose either SCCP or TCP keepalives. TCP keepalives being missed generally trigger SRST much faster than SCCP keepalives being missed.
The phones will register to the GW even if Q.931 backhauling has not been torn down. Hence, there might be a brief period where the phones have registered to the GW but the PRI is still MGCP controlled. In such a case, calls will initially fail. After some time (and this is post the 30 second MGCP KA) the Q.931 backhauling will be torn down (isdn bind-l3 ccm-manager will be removed) and the PRI will function as if it has been configured on an H.323 GW. Here we need to understand that the phones showing "Registering" or "CM Fallback Service Operating" are not indicative of the GW going into SRST. The phones will go into SRST much faster than the Q.931 backhauling being torn down.
The behavior you are seeing is the mechanism for timing out a TCP connection and has nothing to do with the SCCP keepalive itself. Any time the phone sends a TCP packet to the server and does not receive a TCP Ack. The phone will retransmit the packet at decreasing intervals until the session is timed out (phone sends TCP RST) and at that point the phone will failover to the next CCM server or SRST reference.
The SCCP keepalives are sent at regular intervals, based on a value presented to the phone during registration (30 seconds by default). If the phone gets a TCP ack for the keepalive, but no SCCP keepaliveAck from the server then you can get into the situation where the phone unregisters due to keepalive timeout (after 2 or 3 such missed keepaliveAcks).
The former is a network problem, the latter is an application problem where, the network layer of the CCM server is acknowledging that the message was received but the CCM application is not responding.
You will note in your example when the phone registers with the SRST router the sccp Alarmmessage it sends will contain a string like "last=TCP Timeout" or similar.
The 3rd gen phones (7970, 79x1, 79x2, 79x5) are much more aggressive in timing out the TCP session than the 2nd gen phones. What took your 7960 26 seconds to unregister will take a 7965 about 8 seconds.
