The T-bit can be set in a retransmitted Diameter request message as a direct indication that the message may be a duplicate. For example, if the original request message is received by the server, but the answer is lost on its way back to the sender. If the original request message is not received by the server, then the message is not a duplicate from the server point of view. Detection of the duplicates on the application server side is important, especially in credit control applications. Duplicate requests received by the server should not be interpreted as new requests for credit, or new reports for usage, otherwise, double accounting or billing may occur.
On the other hand, the indirect indication of a duplicate Diameter request message on the server side relies on the comparison of the origin-host and end-to-end identifier fields that must always be the same in original and retransmitted messages. This requires the server to keep a history of received messages (or some metadata after it has sent the answer). Normally, after the answer is sent, reference to end-to-end identifier is lost and the duplicate detection is not possible. While some servers may implement such logic to rely on implicit identification of duplicate messages, not all of them are expected to implement such logic. For this reason, setting the T-bit explicitly is a more reliable mechanism to detects duplicates on the server side.
The T-bit in an SR is set on retransmitted messages that are triggered by a timeout (via application) as well as on retransmitted messages triggered by an imminent peer failure.
The T-bit is not set on any message that is retransmitted in response to any explicit error message (3002, 3004, and so on). An explicit error message is an indication that the original request message has reached some Diameter node and solicited a specific response from that node, and therefore is not considered a duplicate.