Avaya S8700 Maintenance Manual page 138

For multi-connect configurations
Hide thumbs Also See for S8700:
Table of Contents

Advertisement

Alarms, Errors, and Troubleshooting
Calls Terminate Correctly but are Unstable
A number of conditions will lead to some or all endpoints having stability problems
during the course of a conference. A lack of stability from an endpoint is
noticeable by a lack of a video switching while the party is the only talker or
excessive disconnects from that endpoint.
Synchronization
Generally, the most common problem is a mismatch in synchronization sources
between the endpoint and the S8700 Multi-Connect MMCH. This typically causes
low-level (Px64) handshake problems that can trigger the endpoint/MMCH to
disconnect the call. The MCCH's timers are set to sufficiently high values so that,
normally, the endpoint will timeout and disconnect first. If installed in a customer
network, it is a good idea to perform an audit of the path synchronization is being
supplied. If there are different clock sources between endpoints and the S8700
Multi-Connect MMCH, some problems are sure to occur. The severity of these
problems can range from a handshake failure every few seconds to one per day.
Depending on the type of endpoint, this can cause the endpoint to disconnect or
just freeze video until the main problem is resolved.
Specifically, PictureTel System 4000 endpoints seem to be the most sensitive to
instability. The Avaya Vistium disconnects fairly infrequently. The CLI Rembrandt
II VP freezes video and waits for framing to be recovered.
Network Configuration Concerns
with Synchronization
When auditing a network for synchronization, avoid unnecessary hops. Thus, a
switch providing star-configuration synchronization is preferred over a daisy-chain
configuration. Additionally, if there are S8700 Multi-Connect systems that have
EPNs, synchronization should be provided to subnodes from the same EPN
through which the system receives its synchronization. Passing synchronization
through a a system's EI:
Adds an unnecessary hop to the path
Creates another potential point of failure
Expansion Interface Duplication
If a customer's network uses EPNs with duplicated EIs, scheduled switching of
the EI links should be disabled on the PBX by using change system-parameters
maintenance. When scheduled maintenance runs and switches the links, there
is a brief corruption of the data path. If endpoints have active calls when the
switch occurs, this corruption of the data path causes Px64 handshake problems
that lead to the endpoints losing video source status and sometimes
disconnecting as described above. Disabling the EI switching is in the customer's
best interest to prevent the disruption of the Px64 data stream. The customer
gets the same level of alarm indications and maintenance on the EI links,
regardless of the status of scheduled switching.
4-64
Issue 1 May 2002
555-233-143

Advertisement

Table of Contents
loading

Table of Contents