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

[Atis Lezdins]

On Mon, Mar 30, 2009 at 5:19 PM, Mark Michelson <mmichelson at digium.com> wrote:
> 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.

I have yet to check this in 1.6 throughly, but is it possible to run
queue answer macro's in combination with Local channels?

Also "stop ringing" is not the correct term for this, as answer might
arrive after phone stopped ringing. There all is about timing, so good
locks have to be in place :)
Additionally - ignoring second answer is not quite good, in case if
first answer macro decides to respond with CONTINUE - call should be
handled to second.


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

I'm currently playing with func_lock backport, and with some hacks
it's becoming usable for this problem.

However the initial idea was to do things right - so that answered
outgoing calls get stacked up within queue and then are chosen
one-by-one. I meant - I could somehow help implementing this in trunk.

Regards,
Atis


-- 
Atis Lezdins,
VoIP Project Manager / Developer,
IQ Labs Inc,
atis at iq-labs.net
Skype: atis.lezdins
Cell Phone: +371 28806004
Cell Phone: +1 800 7300689
Work phone: +1 800 7502835