i have
if (t_check_status("403")) { xlog("L_INFO", "DBG: status is 403\n, rr is <$rr> and rs is <$rs>\n"); };
and i get to syslog:
Oct 18 19:51:37 localhost /usr/sbin/kamailio[18580]: DBG: status is 403 , rr is <<null>> and rs is <<null>>
is this expected behavior?
-- juha
Hello,
On 10/18/08 19:53, Juha Heinanen wrote:
i have
if (t_check_status("403")) { xlog("L_INFO", "DBG: status is 403\n, rr is <$rr> and rs is <$rs>\n"); };
and i get to syslog:
Oct 18 19:51:37 localhost /usr/sbin/kamailio[18580]: DBG: status is 403 , rr is <<null>> and rs is <<null>>
is this expected behavior?
is this in a failure_route? If yes, there is processed the initial request, so the script variable work on it, not on the reply.
Cheers, Daniel
Daniel-Constantin Mierla writes:
is this in a failure_route? If yes, there is processed the initial request, so the script variable work on it, not on the reply.
yes, the test was in failure route. i don't quite understand, why there is script variables that refer to reply items if they are processed on request and not on reply. how could they ever work?
-- juha
On 10/20/08 12:39, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
is this in a failure_route? If yes, there is processed the initial request, so the script variable work on it, not on the reply.
yes, the test was in failure route. i don't quite understand, why there is script variables that refer to reply items if they are processed on request and not on reply. how could they ever work?
they return null as there is no status or reason in a request. It is same from 2003 IIRC when xlog() was introduced and used these variables.
Probably tm module can be enhanced to get these details in the script. t_check_status() has the functionality of checking the reply status code for that transaction, more or less same mechanism can be used to make the status available in a pseudo-variable. Or maybe moving $rr and $rs in tm is an option, but makes them unavailable for stateless processing and onreply_route[0], so might not be a good approach.
Cheers, Daniel
Daniel-Constantin Mierla writes:
Probably tm module can be enhanced to get these details in the script. t_check_status() has the functionality of checking the reply status code for that transaction, more or less same mechanism can be used to make the status available in a pseudo-variable. Or maybe moving $rr and $rs in tm is an option, but makes them unavailable for stateless processing and onreply_route[0], so might not be a good approach.
so should we add a function in tm api that returns the code and reason, which can then be used by pvar module?
now that pvar implementation is still in core, can core also load a module api?
-- juha
-
Daniel-Constantin Mierla -
jh＠tutpro.com