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