Message type, not compatible with call state, or non-existent, or not implemented
Cause
The equipment that sent this cause value receives a message, and the procedures in the protocol specification indicates that this is not a permissible message to receive while in this call state. A STATUS message is received indicating an incompatible call state.
This cause value has local significance only. The ISDN network between the user and the equipment generating the cause value sends:
A no-cause indication through the network
A more generic cause value through the network
Proposed Solution
Check if the protocols at each end of the interface match, for example, both sides are AT&T Custom or both sides are NI-2. If the ends of the interface are using different protocols, the protocols are used with different call state machines or a different message type encoding.
Call state problems are reported with STATUS messages. The equipment sending the cause value uses the CALL STATE IE of the STATUS message to indicate the call state. To determine the call state of the remote end, process the message sequence of the call with the SDL flow charts of the appropriate side (user or network) with the appropriate protocol (TR41449/41459, TR1268, A211 etc.). If the call state at the remote end of the interface does not agree with the call state reported in the STATUS message, and both sides are already using the same protocol, then there is a problem with the implementation of the state machine on either side.
There have been problems with the state machine implementations of some of the CO switches for different protocols, and the state machine problems in the CO switches are most likely not going to be corrected. Communication Manager has not revealed any problems with its state machine implementations for the different protocols.
Change Communication Manager administration to alter the message sequence of the call scenario that causes the error, and help solve state machine implementation problems. For example:
change the transferring message on the DS1 screen from PROGRESS to ALERTING
change the wait steps in vectors to be i-silent so that they do not generate extra PROGRESS messages in the calling message sequence.