This really has me confused. My openser.cfg has the following code:
modparam("lcr","fr_inv_timer",2)
modparam("lcr","fr_inv_timer_next",2)
modparam("tm", "fr_timer", 1)
# Heck, might as well set all three! I don't know the difference between them!
# fr_timer seems to actually cause INVITE's to time out though, unlike fr_inv_timer
and fr_inv_timer_next which do nothing.
...
t_on_failure("2");
if (!next_gw()) {
sl_send_reply("503", "Service not available, no gateways
found");
return;
}
if ( !t_relay() ) {
xlog ("L_INFO","Call to t_relay() returned -1"); # Never
happens even if gateway connection times out
}
else {
xlog ("L_INFO","Call to t_relay() returned 0"); # Always
happens, even when gateway connection times out
}
failure_route[2] {
if (method == "INVITE" ) &&
t_check_status("408|500|503")) {
}
}
Failure route failure_route[2] is being called when t_relay fails to contact a gateway.
I'm still trying to understand how that can actually happen because t_relay() always
returns 0, but anyway.... it seems that calling t_on_failure(2) somehow magically tells
failure_route[2] to execute eventhough the previous t_relay() returns 0. If t_relay()
always returns 0, what triggers execution of failure_route[2]???
Now for the tricky part. Function t_relay() never gets a connection to a gateway, and no
final response code is received. It just so happens I had the t_check_status in there
because I copied and pasted it from someones example. If no final response code is
received, why does this if statement return true? It is returning true eventhough no
response code was received. How can that happen?
Yes, I read the docs on using t_check_status in a failure route block, and it says
"the code of the selected negative final reply". Sounds about what I am talking
about here, although the difference between "the code of the selected negative final
reply" and a reply blocks "the code of the current received reply."
isn't really spelled out anywhere.
And yes, I read the docs. The docs don't explain to me why this weird stuff is
occurring.
Doug.
Show replies by date
Douglas Garstang writes:
And yes, I read the docs. The docs don't explain
to me why this weird
stuff is occurring.
in order to understand how lcr module uses timers, you also need to read
tm module documentation. both tm and lcr modules have fr_inv_timer_avp
parameter and it must be set to same value in both modules.
-- juha