23 Aug
2013
23 Aug
'13
12:13 p.m.
On 23 August 2013 11:18, Steve Davies <steve(a)connection-telecom.com> wrote:
Here's what I put in RELAY route block:
$var(rr) = t_relay();
xlog("L_NOTICE","SLD: in RELAY, t_relay returned
$var(rr)\n");
if (!$var(rr)) {
sl_reply_error();
}
In 4.0.3, t_relay gives a -1 in the case that there is a physical network
issue (in my test I have a "-j DROP" iptables rule)
Trying to find a way to detect the case where t_relay fails but doesn't
call the failure block. I dumped some hopeful looking pseudo variables,
and tried to use an avp to communicate from the failure branch back to the
relay point.
I tried this:
$avp(senttoast) = 0;
$var(rr) = t_relay();
xlog("L_NOTICE","SLD: in RELAY, t_relay returned $var(rr)
err.rcode
is $err.rcode t_r_c is $T_reply_code sent = $avp(senttoast)\n");
if ($var(rr) < 0) {
sl_reply_error();
}
and in my failure block I set $avp(senttoast) to 1.
I get:
Aug 23 12:07:02 ubuntu /usr/local/sbin/kamailio[7819]: NOTICE: <script>:
SLD: in RELAY, t_relay returned -1 err.rcode is <null> t_r_c is 100 sent = 0
In the case of a 477 being sent back. So I can't find anything distinctive
so far.
In the case of a soft failure (I have the upstream send a 500):
Aug 23 12:09:32 ubuntu /usr/local/sbin/kamailio[7817]: NOTICE: <script>:
SLD: in RELAY, t_relay returned 1 err.rcode is <null> t_r_c is 100 sent = 0
So the same.
From the trace I can see that the failure block is only
executed after the
t_relay returns. The failure block runs on a different pid.
So there is a race. Or maybe the avp doesn't work across branches or
something?
Clues would be welcome!
Steve