The sequence of events during recovery and an explanation of what is happening is listed below.
-
If one of the following link failure detected:
Gateway detects a TCP socket failure
TCP socket closure
Catastrophic network error on the link
Lack of a TCP Keep-Alive signal from the endpoint (Keep-Alive Count exceeded).
The TCP Keep-Alive timer on the Procr starts (15 minutes). If the signalling link is still down, the H.323 Link Loss Delay Timer begins.
If the endpoint is on a call when the failure is detected, it tries to re-register with the address(es) of the same Gateway that it was registered with prior to the failure. The endpoint does not wait for the call to be over to re-establish the signaling channels. However, the endpoint does not try to connect to an address of a different Gateway while recovering from a failure encountered during an active call. This is because registering with another Gateway would result in call termination.
If the endpoint is not on a call when the link failure is detected, the endpoint tries to connect to the address(es) of its primary Gateway. If the connection cannot be established with an address of the primary Gateway, the endpoint “marks” the Gateway as “unavailable” and tries to register with the address(es) of the next Gateway in the Alternate Gateway List. If all Gateways are marked, the endpoint stops the registration, “unmarks” all of the Gateway addresses in its list, and then displays an error message to the user.
The TCP Keep-Alive timer on the Procr starts (15 minutes). If the signalling link is still down, the H.323 Link Loss Delay Timer begins.
If the endpoint is on a call when the failure is detected, it tries to re-register with the address(es) of the same Gateway that it was registered with prior to the failure. The endpoint does not wait for the call to be over to re-establish the signaling channels. However, the endpoint does not try to connect to an address of a different Gateway while recovering from a failure encountered during an active call. This is because registering with another Gateway would result in call termination.
If the endpoint is not on a call when the link failure is detected, the endpoint tries to connect to the address(es) of its primary Gateway. If the connection cannot be established with an address of the primary Gateway, the endpoint “marks” the Gateway as “unavailable” and tries to register with the address(es) of the next Gateway in the Alternate Gateway List. If all Gateways are marked, the endpoint stops the registration, “unmarks” all of the Gateway addresses in its list, and then displays an error message to the user.
Note:
During the re-registration process when an endpoint is on an active call, both the Communication Manager server and the endpoint take care that any existing calls are not dropped. In fact, if the re-registration completes successfully, the endpoint regains all call features.
If the endpoint is successful in connecting to the same Gateway, it re-registers, performing what amounts to as a “full” H.323 registration. An internal audit updates the lamp, button, and switchhook information and continues or closes SMDR according to the endpoint state. The Gateway recognizes the endpoint's identity as having previously registered and does not terminate the active call.
As soon as the endpoint detects that the user has hung up, it tries to connect to the address(es) of its primary Gateway if the Gateway Primary Search Timer has not expired yet.
If the connection cannot be established with an address(es) of the primary Gateway or if the Primary Search Time has expired, the endpoint then tries to register with the address(es) of the next Gateway in the Alternate Gateway List.
The endpoint continues its re-registration attempts.
When the H.323 Link Loss Delay Timer expires, the Gateway drops all call state information.
