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? -- David Woolley BTS Holdings Plc Tel: +44 (0)20 8401 9000 Fax: +44 (0)20 8401 9100 http://www.bts.co.uk BTS Holdings PLC - Registered office: BTS House, Manor Road, Wallington, SM6 0DD - Registered in England: 1517630 -- _____________________________________________________________________ -- 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
