On Thu, Feb 6, 2014 at 10:23 AM, Dave WOOLLEY <[email protected]>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
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
