User guide

August 2001 137
Troubleshooting
Handling Protocol Errors
A protocol error occurs when the signaling bits read from the
line don’t match what was expected at that time. For example,
a function detects call answer while monitoring for disconnect.
An unexpected event is not necessarily an error, since there are
times when more than one event could happen. However, the
software returns an error if any event other than the one the
function is waiting for takes place.
The best way to recover from a protocol error is to call
RHT_DISCONNECT to set the local end to idle, then call
RHT_WAIT_IDLE and wait for it to return. When that
happens, both ends are in an idle state and are ready to send or
receive calls. When the line is idle, the application can continue.
Call RHT_GET_STATUS for more information about what
caused the protocol error. RHT_GET_STATUS returns
information about the protocol and compiler version as well as
the termination code and line function information in the
structure RTNI_lineStatus_s.
The ‘TermType’, ‘RawPattern’, and ‘Function’ fields in
RTNI_lineStatus_s contain information to help you handle
protocol errors. Providing these fields to technical support
greatly reduces the time it takes to diagnose a problem.
TermType ‘TermType’ contains the terminating code for the last E1 line
function. If the function is still running, ‘TermType’ contains an
intermediate message or the protocol code for the previous
function. Some protocol codes indicate that the previous
function terminated correctly. For example, a protocol code
might indicate that the RHT_WAIT_LINE_ON function
terminated because it received a call.
Other protocol codes indicate a protocol error. The RealCT
Direct API Reference Manual contains a complete list of protocol
codes and information about how to interpret these values for
different functions.
The protocol codes
BAD_STATE_ERROR and SIGNALING_BIT_ERROR
are common in protocol errors.