On 23 August 2013 11:18, Steve Davies <steve@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!