[asterisk-dev] [Code Review]: Fix Dial I option ignored if dial forked and one fork redirects.

[rmudgett]

> On May 18, 2012, 7:55 a.m., Mark Michelson wrote:
> > I guess I just don't understand why redirecting updates have been removed from app_queue. Obviously with the ringall strategy, it makes sense to remove redirecting updates. But for cases where single members are called, why not send them if a member forwards the call?

After studying the Queue code more, I restored the immediate connected line updates and redirecting updates for non-ringall strategies.  Queues with non-ringall strategies are more like single Dial calls since they normally dial only one member until the timeout.


> On May 18, 2012, 7:55 a.m., Mark Michelson wrote:
> > /branches/1.8/apps/app_dial.c, lines 970-977
> > <https://reviewboard.asterisk.org/r/1920/diff/1/?file=27915#file27915line970>
> >
> >     You could move this up to the part near the top of do_forward where tech gets set to "Local". Channel drivers will not set the tech to "Local" themselves.

I moved the test to right after where tech is set in Dial and Queue.  I still check to see if tech is Local for safety.  I don't think call_forward is ever set to anything with a tech but that doesn't mean something couldn't.


- rmudgett


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1920/#review6253
-----------------------------------------------------------


On May 15, 2012, 11:22 a.m., rmudgett wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1920/
> -----------------------------------------------------------
> 
> (Updated May 15, 2012, 11:22 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> The Dial and Queue I option is intended to block connected line updates and redirecting updates.  However, it is a feature that when a call is locally redirected, the I option is disabled if the redirected call runs as a local channel so the administrator can have an opportunity to setup new connected line information.  Unfortunately, the Dial and Queue I option is disabled for *all* forked calls if one of those calls is redirected.  
> 
> * Make the Dial and Queue I option apply to each outgoing call leg independently.  Now if one outgoing call leg is locally redirected, the other outgoing calls are not affected.
> 
> * Made Dial not pass any redirecting updates when forking calls.  Redirecting updates do not make sense for this scenario.
> 
> * Made Queue not pass any redirecting updates at all.  Queue like FollowMe is either a series of calls or a batch of calls in its search for a queue member to take the call.  Redirecting updates do not make sense for the queue scenario.
> 
> * Fixed deadlock potential with chan_local when sending redirecting updates.
> 
> * Converted the Queue stillgoing flag to a boolean bitfield.
> 
> 
> This addresses bug ASTERISK-19511.
>     https://issues.asterisk.org/jira/browse/ASTERISK-19511
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/apps/app_dial.c 366506 
>   /branches/1.8/apps/app_queue.c 366506 
> 
> Diff: https://reviewboard.asterisk.org/r/1920/diff
> 
> 
> Testing
> -------
> 
> Dialed using the I option with and without forking the call.  Connected line updates are blocked until the call is locally redirected.  For forked calls, only the leg that locally redirected the call updated the connected line information.
> 
> Called a queue using the I option with and without members redirecting the call.  The queue rang all available members.  Members that took the call without locally redirecting the call did not update the connected line information.  Members that locally redirected the call did update the connected line information.
> 
> 
> Thanks,
> 
> rmudgett
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120519/ee201c80/attachment-0001.htm>