[asterisk-dev] Queue strategy with Ringall and multiple agents answering simultenously.

[Mark Michelson]

Atis Lezdins wrote:
> Hello,
> 
> This is a request for discussion of http://bugs.digium.com/view.php?id=13335
> 
> 
> I am trying to find a solution for the following scenario:
> 
> Queue (ringall) -> Local channel -> Dial(SIP/device,M(answer_macro))
> 
> For Asterisk 1.6 it could be a GoSub, but still, there's no easy
> exclusive way how to allow only one person to answer at a time.
> 
> The problem is that whenever two agents answer a call simultenously
> (which does happen in real world), both answer macro's start executing
> in parralel.
> 
> I consider this a bug, and also putnopvut recognized this as such, but
> considering it's not an easy change, it could go to 1.6.1 or whatever
> big release.
> 
> I'm willing to help on testing or even writing some code, if You can
> help with architecture of this and how it should be implemented. I was
> thinking of some datastore set for local channels created by queue and
> checked/callback from Dial app.
> 
> Regards,
> Atis
> 

(in case it's not clear, I am putnopvut that Atis referred to in his message)

David Vossel and I discussed this bug at great length when seeing just how we 
could fix it. Unfortunately, for 1.4, the best we could think of is that the 
answer_macro could call a MacroExclusive so that the macro will run only on one 
member's channel. Use of a global variable in the dialplan could also be helpful 
in deciding whether to attempt running the MacroExclusive that the answer_macro 
calls. The problem is that it just is not feasible for separate instances of the 
Dial application to be "aware" of each other.

For 1.6.X, there already exists a really easy way to get around your issue. 
app_queue can actually run the macro or gosub on the answering member's channel 
instead of app_dial. Since it is app_queue which is running the macro, the other 
members' phones will immediately stop ringing as soon as someone answers the call.

If you're willing to try to write some code for 1.4, then I'm certainly not 
going to stop you :) The problem is that as far as I am concerned, the 
cost-to-benefit ratio of fixing this issue is much too high, especially since 
there seem to be suitable workarounds in the dialplan.

Mark Michelson