Avaya MCC1 Maintenance Procedures page 143

During the recovery process, when the IP endpoint is attempting to re-register, the customer will
experience some noticeable anomalies in the handling of some features or capabilities:
• An IP endpoints will not have dial-tone for a new call.
• Music or announcement sources connected to a call that includes an IP endpoint that has lost its
signaling connection to the Gateway will remain in the context even if all parties to the call hang
up.
• AUDIX connections timeout after the IP endpoint caller has left a message and hung up.
• If the outage persists for several minutes, the statistics for BCMS, CMS, call attendants, and other
time-related reports might be inaccurate.
• If the endpoint hung up during the link recovery process, SMDR records will be inaccurate for the
link recovery time period.
• The following IP Telephone buttons do not work:
— TouchTone pad
— Feature access buttons (Hold, Conference, etc.)
— Administrable buttons
• The server maintains call state information for the IP endpoint for the duration of the H.323 Link
Loss Delay Timer plus 15 minutes. At that time Communication Manager deletes the IP
endpoint's call state, so that when the call ends, the IP endpoint must re-register. If the endpoint is
operating in 'telecommuter' mode, this timer does not apply.
Keep-Alive signals
IP Endpoints transmit either RAS Keep-Alive (the default) or TCP Keep-Alive signals. Through the use
of Gateway-to-IP endpoint messaging, the IP endpoint transmits a compatible Keep-Alive message as
instructed by the Gateway.
The RAS Keep-Alive signal frequency increases with an ever-increasing number of registered IP
endpoints. To reduce the volume of the Keep-Alive messages on a server, Communication Manager
varies the RAS time-to-live (TTL) value based on the number of registered IP endpoints and the server
platform (DEFINITY series, S8700, S8500, S8300, and S8100). However, continually increasing the
TTL to accommodate more IP endpoints eventually reaches a point where the time to detect and recover
from a temporary signaling loss between the server (Gateway) and endpoint is unacceptable. For this
reason both the endpoint and the Gateway (Communication Manager server) use TCP Keep-Alive
messages to status the call signaling channel.
Communication Manager monitors a low-frequency TCP Keep-Alive signal from the Gateway to an
endpoint to detect whether the endpoint is still accessible. This Keep-Alive allows the Gateway to detect
call signaling channel failures in cases where the IP endpoint may have migrated to an LSP or has simply
failed. If the IP endpoint is accessible, then it sends a TCP Keep-Alive signal to its Gateway (server)
whenever the TCP connection is idle.
The TCP Keep-Alive mechanism for an endpoint depends on the:
• Idle Traffic Interval (see
• TCP Keep-Alive Interval (see
144)
• Keep-Alive Count (see
145)
Maintenance Procedures
December 2003
Figure 19, Idle Traffic Interval,
Figure 20, Keep-Alive signals acknowledged by Gateway,
Figure 21, Keep-Alive signals not acknowledged by Gateway,
Server initialization, recovery, and resets
on page 144)
Link Recovery
on page
on page
143