[Users] ACK Routing: Best practices?

[Carsten Bock]

Hi everybody,

Short question: Are there any best practices regarding the routing of 
ACK Messages?
Currently we have the following logic implemented:

route {
    [...]
    
##################################################################################################################
    # Check for Re-Transmissions (not ACK/CANCEL)
    
###############################################################################################################
    if ((method != "CANCEL") && (method != "ACK")) {
        if (t_check_trans()) {
            log(1, "Re-Transmission detected, message dropped.\n");
            # Drop the message silently.
            return;
        }
    }
   
    
##################################################################################################################
    # Loose-Routing (RFC3261)
    
###############################################################################################################
    if (loose_route()) {
        route(10);
        return;
    }; # if (loose_route()) { 
   
    
##################################################################################################################
    # ACK/CANCEL Messages may be relayed
    
###############################################################################################################
    if ((method == "CANCEL") || (method == "ACK")) {
        if (uri != myself) {
            #  Und das Paket entsprechend weiterleiten
            if (!t_relay("udp:outbound_proxy:outbound_proxy_port")) {
                log(1, "Not possible to relay\n");
                # Fehler melden
                sl_reply_error();
                return;
            }
            return;
        }
    }
    [...]
    
##################################################################################################################
    # Rest of "normal" Routing logic with number manipulation / Routing 
to different Gateways / User Authorization/Authentication
    
###############################################################################################################
}

Is there any other method, to improve the routing of ACK/CANCEL 
Messages? I would like to avoid all the number manipulation, checking 
and choosing of a proper gateway....
I thought, this must (somehow) be possible since from a technical 
perspective the ACK and CANCEL Message can be associated with a 
corresponding INVITE Message (and the corresponding Transaction).
I've looked in the manual of the TM-Module and found the following example:
if ( is_method("CANCEL") ) {
if ( t_check_trans() )
t_relay();
exit;
}
(http://openser.org/docs/modules/1.1.x/tm.html#AEN460)

I guess, this example does not mean, that the URI gets rewritten 
properly and the CANCEL-/ACK-Message would get properly relayed to the 
destination, where it is supposed to end.
Is there any way to do it best? I've seen, that some clients do proper 
loose-routing for ACK-Messages, but not all clients, so this is not a 
solution.
Are there any other suggestions?

Thanks in advance,

Carsten



____________
Virus checked by G DATA AntiVirusKit