18 Oct
2008
18 Oct
'08
7:53 p.m.
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
20 Oct
20 Oct
12:29 p.m.
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
http://www.asipto.com
12:39 p.m.
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
12:54 p.m.
On 10/20/08 12:39, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
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
http://www.asipto.com
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?
4:37 p.m.
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
5877
days inactive
5879
days old
4 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
jh＠tutpro.com