Troubleshooting association problems

If both endpoints are active, are configured correctly, and have network connectivity, an association is created successfully. If an association was not established, troubleshoot the problem as described in the following table:

Task	Description
1	Examine the txalarm log for error messages that explain the cause, such as configuration or communication errors. Refer to Starting txalarm for information.
2	Examine the configuration files to ensure that: The M3UA primary destination address (PRIME_DEST_ADDR) matches the other side’s actual IP address. The routing contexts match the routing contexts on the other side. One side has the CLIENT_SIDE parameter set to TRUE so that it initiates associations. Refer to M3UA configuration reference for information.
3	Use the cpcon ping command to determine that the other side is reachable over the IP network. Refer to the TX Utilities Manual for information.
4	Turn on data tracing in SCTP (and M3UA) to see the sent and received messages. In the sctpmgr or m3uamgr utilities, use the trace ena command.
5	Turn on debug logging in SCTP (and M3UA) to cause additional log information to be sent to txalarm. In the sctpmgr or m3uamgr utilities, use the debug ena command.

Refer to the Dialogic® NaturalAccess™ SIGTRAN Stack Developer's Reference Manual for information about the sctpmgr and m3uamgr utilities.

Loss of an existing association

If an association already exists when one or the other side reboots, it may take time to re-establish the association, depending on which side rebooted.

If the side that initiates the association (client side) reboots, the association is re-established immediately upon successful reload.
If the side that waits for the initiation of an association (server side) reboots, it may take time for the client side to realize that the server side has rebooted.

The only method that the system has to determine that the association is gone is when messages go unacknowledged. It takes MAX_DEST_RETRY (default 5) unacknowledged messages before SCTP declares the association terminated and M3UA attempts to re-establish it. If there is no data traffic (only heartbeats are being sent), it takes at least TMR_HB_INTERVAL (default 3 seconds) times MAX_DEST_RETRY for the loss of association to be detected. These parameters can be reduced to speed up the detection of loss of an association. Refer to SCTP configuration reference for information.