Application level Diameter request messages originated from an SR node can be retransmitted in response to either an error messages received from the Diameter peer or server, or because of a lack of acknowledgment (Diameter Answer message or a TCP ACK) received from a Diameter peer or server.
Message retransmissions can occur on multiple levels:
TCP level where a TCP ACK is not received from a peer. Such retransmission cannot traverse Diameter nodes (for example between the originating node and the destination node that are separated by one or more intermediate Diameter nodes). They work only between Diameter peers.
The lack of TCP ACK can be caused by some anomaly in transmission lines or congestion in the network or the peering node where the TCP packets are dropped.
The Diameter Base level where they are triggered by the peer failover procedures that can be caused by the peer failure or the receipt of DIAMETER_UNABLE_TO_DELIVER (3002) and DIAMETER_TOO_BUSY (3004) error messages. The peer failover (and retransmission on the Diameter base level) is performed only for the messages that directly solicit 3002/3004 error response.
On the Diameter application level (NASREQ, Gx, Gy) retransmissions are sent only if the server failover functionality is enabled:
*A:node1>config>subscr-mgmt>diam-appl-plcy# on-failure
failover {enabled|disabled}
handling {continue|retry-and-terminate|terminate}
On the Diameter application level, the request message is retransmitted only one time. Retransmissions on the Diameter application level are triggered by:
Answer messages that have the E-bit set (protocol error). The only two exceptions are DIAMETER_UNABLE_TO_DELIVER (3002) and DIAMETER_TOO_BUSY (3004) error messages that trigger retransmissions on the Diameter Base level until all viable Diameter paths are exhausted, or the Tx timer expires (whichever event occurs first). Only after all viable paths are exhausted, or the Tx timer expires, the handling is passed to the Diameter application which has the option to retransmit the message one last time, with the destination-host AVP cleared.
Notification by the Diameter base that the path to the destination-realm is unavailable. For example, because of Tx-timer timeout, the answer to an original request message is not received within the time window determined by this configurable timer.
Answer messages are never retransmitted on the Diameter application level. However, Answer messages can be retransmitted on a TCP level.
Retransmission of non-routable Diameter request messages is driven by an internal timer which is set to a fixed value of 10 seconds. Non-routable Diameter messages are messages required for maintenance of the peering connection. These messages never propagate beyond the peer. This internal timer is used in the following cases:
Failure to initiate TCP peering connection
Incomplete Capability Exchange
If the response to the CER message (CEA) is not received within 10 seconds, the peer connection is closed and the connection-timer is restarted. The expiry of the connection-timer triggers a new connection request.
Peer Disconnect Request
If the response to the DPR message is not received (DPA) within 10 seconds, the peer connection is closed.
Diameter Watchdog messages are an exception and they are not retransmitted. Watchdog messages are used to detect the liveliness of a peer. A Diameter Watchdog message is sent in absence of any traffic on the peer level and only when the peer level watchdog-timer expires.