1 Aug
2006
1 Aug
'06
7:43 p.m.
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