Diameter_Unable_to_Deliver (3002) is a protocol error message with E-bit set that is handled on a hop-per-hop basis (the node receiving this message must handle it and not just transparently pass it to the next node). 3002 is a response to an application request message, and its purpose is to notify the sender (the first upstream Diameter node) that the intended destination for this particular application and within this realm is not available on that path. This should trigger the node that receives such a response to retransmit the request message over an alternate path, that is the next peer found in the realm routing table.
After all eligible next hop peers are exhausted, or the Tx timer expires, the Diameter application is notified that the message request has failed. A configurable Tx timer is started after the first peer failover is performed (reaction to the first 3002 or 3004 error message received). All this is in the context of a single application request message. At this point the Diameter application determines, based on the server failover configuration, whether to retransmit this message. The destination-host AVP is cleared in retransmitted message.
For example:
A 3002 message is received by the Diameter Base in the SR
The TX timer is started
The Diameter Base denylists the peer from which this message is received
The request message in the pending queue is immediately re-transmitted to the next eligible peer
This process continues until a viable peer is found (a request message is successfully delivered to the destination), the last eligible peer is tried, or the Tx timer expires, whichever event occurs first. The subsequent eligible peers can be only found in the realm routing table (and not the peering table).
If the message is not successfully delivered within the Tx time, the Diameter Base notifies the application layer (NASREQ, Gx, Gy).
The application executes the server failover procedure and potentially retransmit the request.
At this point the application clears the destination-host AVP and the message is delivered to any server in the same realm supporting this application. This assumption is that the application servers support geo-redundancy.