[asterisk-dev] 302 redirects ocassionally ignored; hypothesis: later queued busy preferred to earlier early media frame

[Richard Mudgett]

On Thu, Feb 6, 2014 at 10:23 AM, Dave WOOLLEY <dave.woolley at bts.co.uk>wrote:

> 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?
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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?
>

Without looking into the code, queueing a busy frame to wake up the read
thread and look at the call-forward string seems wrong.  The null frame
should be queued instead.

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140206/a3056e44/attachment.html>