<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 6, 2014 at 10:23 AM, Dave WOOLLEY <span dir="ltr"><<a href="mailto:dave.woolley@bts.co.uk" target="_blank">dave.woolley@bts.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We have a situation where about 1% of incoming 302 responses result in the call failing as busy, rather than redirecting.  We are using a heavily patched 1.6.1.0, however we have a theory for the mechanism that still seems to be valid on Asterisk 12.  Could anyone verify the analysis and comment on our current proposed solution, or suggests alternatives?<br>

<br>
We are making calls, actually via an ApplianX gateway and iSDX, that can end up with a 302 redirect to the voicemail number, if there is no answer.  We have Asterisk configured for promiscuous redirects.  Most of the time  these work.  However, of the order of 1% of the times, the 302 is received (sip debug), and recognized, RDNIS is logged (back port), but the Dial operation ends up failing with a busy status.  The interim response before the 302 is a 180 with SDP.<br>

<br>
Our understanding of what happens is that redirects are passed from the channel driver to Dial by setting a call forward string in the channel structure, then pushing AST_CONTROL_BUSY into the channel's queue, and writing to the alertpipe to wake things up.<br>

<br>
When woken up, Dial checks for the presence of the forwarding string, and goes into the redirect processing.  If it doesn't find it, it calls ast_read.  Amongst other things, ast_read first tries to read from the queue, then, if there is nothing there, reads from the channel driver, adding everything after the first frame retrieved onto the queue.<br>

<br>
If everything arrives from the channel driver, this is the correct order of processing, however, if something is pushed directly onto the queue, like the AST_CONTROL_BUSY, it will have precedence over frames that were available earlier from the channel driver.<br>

<br>
Our current hypothesis is that an early media frame arrives on the RTP socket.  This causes the ast_waitfor_n in Dial to wake up.  Just after it passes the check for a redirection (c->call_forward), the 302 arrives and sets the redirection and queues the AST_CONTROL_BUSY.  When Dial reaches the ast_read, it reads the AST_CONTROL_BUSY without having seen the redirection address and aborts the call.<br>

<br>
The simplest approach to this would be to delay do_transfer until after the ast_read.  Are there any reasons why this might not be safe?<br></blockquote><div><br></div><div>Without looking into the code, queueing a busy frame to wake up the read <br>
thread and look at the call-forward string seems wrong.  The null frame <br>should be queued instead.<br><br></div><div>Richard<br></div></div><br></div></div>