Hi Bogdan:<br>  After patching the failure route the way you said, the problem seems to be solved. <br>  About your question, as far as I know, no branches are created, implicitly or explicitly. $bR is &lt;null&gt; before the t_relay.<br>
Thanks:<br>Francisco <br><br><div class="gmail_quote">2009/5/25 Bogdan-Andrei Iancu <span dir="ltr">&lt;<a href="mailto:bogdan@voice-system.ro">bogdan@voice-system.ro</a>&gt;</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Francisco,<br>
<br>
First of all, please in the begining of any failure route:<br>
<br>
failure_route[x] {<br>
   if (t_was_cancelled()) {<br>
       exit;<br>
   }<br>
   .....<br>
}<br>
<br>
This will capture the calls which were cancelled by the caller and avoid any bogus processing on the cancelled call.<br>
<br>
<br>
Now, in regards to the &quot;Contact&quot; stuff, before the t_reply(&quot;3xx&quot;), do you use create any new branch (via append_branch or other functions that do it internally)? I&#39;m asking because when you do a 3xx reply, automatically, the newly set ruri and any created branches are used in the reply contact. To check  this, you may print the &quot;*$bR* &quot; var from the script, before the t_relay();<div class="im">
<br>
<br>
Regards,<br>
Bogdan<br>
<br>
<br>
Francisco Javier Lizaran Vilches wrote:<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
Hi:<br>
    I caught the failure again with logs enabled. First of all, I&#39;ve realized that I made a mistake explaining the issue before. There is no problem with forward busy at all as I said. The problem appears with forward on no answer only, so this is the part of the script to take into account:<br>

<br>
route[3]    {<br>
...<br>
t_on_failure(&quot;1&quot;);<br>
...<br>
        # forward on no answer<br>
        if (is_avp_set(&quot;$avp(s:fwdnoanswer)/s&quot;)) {<br>
                if ($ru==$avp(s:fwdnoanswer)) {<br>
                        sl_send_reply(&quot;603&quot;, &quot;Decline&quot;);<br>
                        return;<br>
                };<br>
                setflag(24);<br>
        };<br>
...<br>
}<br>
<br>
failure_route[1] {<br>
        if ((isflagset(24)) &amp;&amp; (t_check_status(&quot;408&quot;))) {<br>
                xlog(&quot;L_NOTICE&quot;, &quot;Fwdnoanswer: $avp(s:fwdnoanswer) \n&quot;);<br>
                if (avp_pushto(&quot;$ru&quot;, &quot;$avp(s:fwdnoanswer)&quot;)) {<br>
                        avp_print();<br>
                        t_reply(&quot;302&quot;,&quot;Moved Temporarily&quot;);<br>
                        return;<br>
                        };<br>
                };<br>
        };<br>
...<br>
}<br>
<br>
    So, for example, user 20173 calls user 20346 which has a fwd to 20559. After ring timeout expires, the proxy sends back to user 20173 a 302 response. In the contact header appears 20559 and another uri appended:<br></div>

    Contact: <a href="mailto:sip%3A20559@domain.com" target="_blank">sip:20559@domain.com</a> &lt;mailto:<a href="mailto:sip%253A20559@domain.com" target="_blank">sip%3A20559@domain.com</a>&gt;, &lt;sip:066012...@10.100.2.254:5060;transport=udp&gt;;q=0<div class="im">
<br>
<br>
    This uri is included along all the forwardings on no answer performed in the system.<br></div>
       Looking at the log, there is no trace of such uri in the avp list:       openser[11278]: Fwdnoanswer: <a href="mailto:sip%3A20559@domain.com" target="_blank">sip:20559@domain.com</a> &lt;mailto:<a href="mailto:sip%253A20559@domain.com" target="_blank">sip%3A20559@domain.com</a>&gt;<div class="im">
<br>
    ...<br>
    openser[11278]: INFO:avpops:print_avp: p=0xb57356a8, flags=0x0083<br>
    openser[11278]: INFO:            name=&lt;fwdnoanswer&gt;<br></div>
    openser[11278]: INFO:            val_str=&lt;<a href="mailto:sip%3A20559@domain.com" target="_blank">sip:20559@domain.com</a> &lt;mailto:<a href="mailto:sip%253A20559@domain.com" target="_blank">sip%3A20559@domain.com</a>&gt; / 23&gt;<div class="im">
<br>
    ...<br>
<br>
    Searching through the log back in time I have seen the last call to uri 66012...     openser[11278]: ERROR:tm:t_forward_nonack: discarding fwd for a cancelled/6xx transaction<br>
    openser[11278]: ERROR:tm:w_t_relay: t_forward_nonack failed<br>
    openser[11278]: T_RELAY ERROR: remote URI: sip:076660129671@10.100.222.202:5060;transport=udp<br>
       That time there was a correct forward no answer to this number, but t_relay got an error after cancelling. Probably it is related with later issues when forwarding.<br>
       Regards:<br>
    Francisco<br>
<br></div>
2009/5/4 Francisco Javier Lizaran Vilches &lt;<a href="mailto:fran.lizaran@gmail.com" target="_blank">fran.lizaran@gmail.com</a> &lt;mailto:<a href="mailto:fran.lizaran@gmail.com" target="_blank">fran.lizaran@gmail.com</a>&gt;&gt;<div class="im">
<br>
<br>
    Hi Bogdan:<br>
<br>
    I will try to print the avp next time it occurs.<br>
<br>
    Thanks:<br>
<br>
    Francisco<br>
<br>
    2009/4/30 Bogdan-Andrei Iancu &lt;<a href="mailto:bogdan@voice-system.ro" target="_blank">bogdan@voice-system.ro</a><br></div>
    &lt;mailto:<a href="mailto:bogdan@voice-system.ro" target="_blank">bogdan@voice-system.ro</a>&gt;&gt;<div><div></div><div class="h5"><br>
<br>
        Hi Francisco,<br>
<br>
        First of all, maybe it will be a good idea to upgrade to<br>
        OpenSIPS 1.5.1 - along the versions many bugs were fixed and<br>
        1.2 is a really old one.<br>
<br>
        Have you tried to place an xlog and print the fwdbusy avp just<br>
        before the avp_pushto() ?<br>
<br>
        Regards,<br>
        Bogdan<br>
<br>
<br>
        Francisco Javier Lizaran Vilches wrote:<br>
<br>
            Hi all:<br>
            Have  running this script on Openser 1.2.3-notls version<br>
            managing forwards this way:<br>
<br>
            route[3]    {<br>
            ...<br>
            t_on_failure(&quot;1&quot;);<br>
            if avp_db_load(&quot;$ru&quot;, &quot;*&quot;) {<br>
                   if (is_avp_set(&quot;$avp(s:fwdbusy)/s&quot;)) {<br>
                           setflag(23);<br>
                   };<br>
            ...<br>
<br>
            failure_route[1] {<br>
            ...<br>
                   if ((isflagset(23)) &amp;&amp; (t_check_status(&quot;486&quot;))) {<br>
                           if (avp_pushto(&quot;$ru&quot;, &quot;$avp(s:fwdbusy)&quot;)) {<br>
                                   t_reply(&quot;302&quot;,&quot;Moved Temporarily&quot;);<br>
                                   return;<br>
                                   };<br>
                   };<br>
            ...<br>
<br>
            User A calls user B and B has fwdbusy parameter set in<br>
            user preferences; if B is busy, proxy sends 302 message<br>
            back to A with contact set to $avp(s:fwdbusy) value. This<br>
            setup usually works fine. However, sometimes the proxy<br>
            shows a strange behaviour. It starts to append an<br>
            arbitrary contact to the contact header in every<br>
            forwarding it does. The contact appended has nothing to do<br>
            with A or B or the uri set in the avp. The same uri is<br>
            appended in all call forwardings performed in the system.<br>
            If the proxy is restarted, the problem disappears.<br>
<br>
            Example:<br>
<br>
            SIP/2.0 302 Moved Temporarily<br>
            Via: SIP/2.0/UDP 10.100.2.254:5060;branch=z9hG4bK51461DD5<br>
            From: &lt;<a href="mailto:sip%3A30132@10.100.2.254" target="_blank">sip:30132@10.100.2.254</a><br>
            &lt;mailto:<a href="mailto:sip%253A30132@10.100.2.254" target="_blank">sip%3A30132@10.100.2.254</a>&gt;<br>
            &lt;mailto:<a href="mailto:sip%253A30132@10.100.2.254" target="_blank">sip%3A30132@10.100.2.254</a><br></div></div>
            &lt;mailto:<a href="mailto:sip%25253A30132@10.100.2.254" target="_blank">sip%253A30132@10.100.2.254</a>&gt;&gt;&gt;;tag=92DAB388-EE7<div class="im"><br>
            To: &lt;<a href="mailto:sip%3A20050@domain.com" target="_blank">sip:20050@domain.com</a> &lt;mailto:<a href="mailto:sip%253A20050@domain.com" target="_blank">sip%3A20050@domain.com</a>&gt;<br>
            &lt;mailto:<a href="mailto:sip%253A20050@domain.com" target="_blank">sip%3A20050@domain.com</a><br></div>
            &lt;mailto:<a href="mailto:sip%25253A20050@domain.com" target="_blank">sip%253A20050@domain.com</a>&gt;&gt;&gt;;tag=880a5593aeb097bc75600b31d6e17107-78ac<div class="im"><br>
            Call-ID: <a href="mailto:C0C84A1C-33CE11DE-BEBEEAA9-C0D323DF@192.168.2.40" target="_blank">C0C84A1C-33CE11DE-BEBEEAA9-C0D323DF@192.168.2.40</a><br>
            &lt;mailto:<a href="mailto:C0C84A1C-33CE11DE-BEBEEAA9-C0D323DF@192.168.2.40" target="_blank">C0C84A1C-33CE11DE-BEBEEAA9-C0D323DF@192.168.2.40</a>&gt;<br>
            &lt;mailto:<a href="mailto:C0C84A1C-33CE11DE-BEBEEAA9-C0D323DF@192.168.2.40" target="_blank">C0C84A1C-33CE11DE-BEBEEAA9-C0D323DF@192.168.2.40</a><br>
            &lt;mailto:<a href="mailto:C0C84A1C-33CE11DE-BEBEEAA9-C0D323DF@192.168.2.40" target="_blank">C0C84A1C-33CE11DE-BEBEEAA9-C0D323DF@192.168.2.40</a>&gt;&gt;<br>
            CSeq: 101 INVITE<br>
            Contact: <a href="mailto:sip%3A30050@domain.com" target="_blank">sip:30050@domain.com</a><br>
            &lt;mailto:<a href="mailto:sip%253A30050@domain.com" target="_blank">sip%3A30050@domain.com</a>&gt;<br>
            &lt;mailto:<a href="mailto:sip%253A30050@domain.com" target="_blank">sip%3A30050@domain.com</a><br></div>
            &lt;mailto:<a href="mailto:sip%25253A30050@domain.com" target="_blank">sip%253A30050@domain.com</a>&gt;&gt;,<div class="im"><br>
            &lt;sip:030410@10.172.0.254:5060;transport=udp&gt;;q=0<br>
<br>
            Server: OpenSER (1.2.3-notls (i386/linux))<br>
            Content-Length: 0<br>
<br>
<br>
            &lt;sip:030410@10.172.0.254:5060;transport=udp&gt;;q=0 is added<br>
            in all forwardings done the system.<br>
<br>
            Unfortunately I have no debug info cause it happens in<br>
            production environment. I couldn&#39;t reproduce the problem<br>
            in test environment. Have you got any idea on what could<br>
            make it happen?<br>
<br>
            Thanks a lot:<br>
            Fran Lizaran<br>
            ------------------------------------------------------------------------<br>
<br>
            _______________________________________________<br>
            Users mailing list<br></div>
            <a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a> &lt;mailto:<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a>&gt;<div class="im"><br>

            <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
             <br>
<br>
<br>
<br>
<br>
    --     Fran Lizaran<br>
    Comprometido con el Derecho a Vivir<br>
    <a href="http://derechoavivir.org" target="_blank">http://derechoavivir.org</a><br>
<br>
<br>
</div></blockquote>
<br>
</blockquote></div><br><br clear="all"><br>-- <br>Fran Lizaran<br>Comprometido con el Derecho a Vivir<br><a href="http://derechoavivir.org">http://derechoavivir.org</a><br>