[Users] t_check_status

Douglas Garstang dgarstang at oneeighty.com
Sat Nov 26 07:49:24 CET 2005


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.
 
 
 
 
 

 


More information about the Users mailing list