Avaya 555-245-600 Manual Do Utilizador
IP endpoint recovery
Issue 6 January 2008
275
The link recovery process follows these steps:
1. While SLS is enabled and processing, the media gateway continues to seek an alternative
media gateway controller.
2. If Avaya Communication Manager accepts the registration then the active IP to IP calls that
shuffle are preserved.
3. The SLS application stops processing any new calls and goes to inactive mode.
IP endpoint recovery
Avaya’s distributed IP-based systems can also enjoy increased availability by virtue of the
“alternate gatekeeper.” When IP Telephones register with Communication Manager, they are
given a list of “alternate gatekeepers” to which they can re-register in the event of a failure.
Thus, if a C-LAN fails or becomes unavailable, users that are registered to that C-LAN can
re-home to another C-LAN that is unaffected by the failure.
“alternate gatekeeper.” When IP Telephones register with Communication Manager, they are
given a list of “alternate gatekeepers” to which they can re-register in the event of a failure.
Thus, if a C-LAN fails or becomes unavailable, users that are registered to that C-LAN can
re-home to another C-LAN that is unaffected by the failure.
IP endpoint recovery
The Avaya servers are designed to have a scalable architecture with different server
components. These components provide processing and relay signaling information between
Communication Manager and the Avaya IP endpoints. The system architecture is inherently
distributed, providing the scalability to support a large number of endpoints and the flexibility to
work in various network configurations.
This distributed nature of the architecture introduces additional complexity in dealing with
endpoint recovery, since failure of any element in the end-to-end connectivity path between an
IP endpoint and the switch software can result in service failure at the endpoint.
The recovery algorithm that is outlined here deals with detection and recovery from the failure of
signaling channels for IP endpoints. Such failures are due to connectivity outages between the
server and the endpoint, which could be due to failure in the IP network or any other component
between the endpoint and the server.
In the S8500 and S8700-series configurations the connectivity path between the endpoint and
the server is:
components. These components provide processing and relay signaling information between
Communication Manager and the Avaya IP endpoints. The system architecture is inherently
distributed, providing the scalability to support a large number of endpoints and the flexibility to
work in various network configurations.
This distributed nature of the architecture introduces additional complexity in dealing with
endpoint recovery, since failure of any element in the end-to-end connectivity path between an
IP endpoint and the switch software can result in service failure at the endpoint.
The recovery algorithm that is outlined here deals with detection and recovery from the failure of
signaling channels for IP endpoints. Such failures are due to connectivity outages between the
server and the endpoint, which could be due to failure in the IP network or any other component
between the endpoint and the server.
In the S8500 and S8700-series configurations the connectivity path between the endpoint and
the server is:
Endpoint
⇔
IP network
⇔
C-LAN
⇔
PN backplane
⇔
IPSI
⇔
IP network
⇔
S8700
In this configuration, IP endpoints register to C-LAN on the PN. The DEFINITY platforms G3r,
G3si, and G3csi, which support Avaya Application Solutions features, also use C-LAN for
signaling connecting to IP endpoints.
G3si, and G3csi, which support Avaya Application Solutions features, also use C-LAN for
signaling connecting to IP endpoints.