[asterisk-bugs] [Asterisk 0013335]: Multiple agents answering a call.

Asterisk Bug Tracker noreply at bugs.digium.com
Thu Mar 12 18:14:00 CDT 2009


The following issue has been CLOSED 
====================================================================== 
http://bugs.digium.com/view.php?id=13335 
====================================================================== 
Reported By:                atis
Assigned To:                dvossel
====================================================================== 
Project:                    Asterisk
Issue ID:                   13335
Category:                   Applications/app_queue
Reproducibility:            sometimes
Severity:                   major
Priority:                   normal
Status:                     closed
Asterisk Version:           1.4.21.1 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
Resolution:                 open
Fixed in Version:           
====================================================================== 
Date Submitted:             2008-08-18 11:16 CDT
Last Modified:              2009-03-12 18:14 CDT
====================================================================== 
Summary:                    Multiple agents answering a call.
Description: 
Scenario

Queue (ringall) -> Local channel -> Dial(SIP/device,M(answe_macro))

If two or more agents answer simultaneously, answer macro of Agent 1
starts excuting, then answer macro of Agent 2 starts executing and so on.
One of those answer macros ends first, and this call is bridged. However
logics of answer macros may include some important logic which should be
executed only upon bridging. 

So, there is no way how to know which agent has actually answered. Also
CDR is marked ANSWERED for all agents answering at the same time.

Whenever first channel is answered, it should somehow block all other
parallel channels (originating from the same queue entry) from executing
answer macro, until result of first channel is known. If first channel is
bridged, other threads should return DIALSTATUS=CANCEL. Otherwise if first
channel sets MACRO_RESULT to something (indicating that it won't bridge the
call), other threads should resume one by one executing their own answer
macro's.


====================================================================== 

---------------------------------------------------------------------- 
 (0101701) dvossel (administrator) - 2009-03-12 18:14
 http://bugs.digium.com/view.php?id=13335#c101701 
---------------------------------------------------------------------- 
In 1.4, a macro can't execute within Queue() app, so it has to execute it
within the Dial() app.  Since the Queue() app has no control of the
executed macro, it turns out to be an enormous task to achieve what you're
asking, one that probably isn't acceptable to put into 1.4.  I don't
believe this is a bug either.  What you have set up is working as expected,
it would just be nice if there were an easy way to do what you're wanting. 
There are a few options available though.  You could attempt to do use the
MacroExclusive() app and use a global variable to determine whether or not
the call was accepted.  If you were willing to update to 1.6, you could
execute the macro within the Queue() app which provides more control. 
Sorry there doesn't appear to be an easy solution.  Hopefully this helps. 
I'm going to go ahead and close this issue, feel free to reopen it if you
deem it necessary.  Due to the complexity involved, it might be worth bring
this up on the asterisk-dev mailing list if you have further comments. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-03-12 18:14 dvossel        Note Added: 0101701                          
2009-03-12 18:14 dvossel        Status                   acknowledged => closed
======================================================================




More information about the asterisk-bugs mailing list