Summary:	ASTERISK-09544: After QueuePause(true) and queue inboundcall is delivered to sip
Reporter:	dmb (dmb)	Labels:
Date Opened:	2007-05-30 05:31:52	Date Closed:	2007-08-06 18:04:17
Priority:	Trivial	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Hello, When an agent state is changed with manager queuepause(Paused:true) action and inboundcall is trying to route to that agent at same second (but milisecons after), the call is routed to that agent without giving way the previous queuepause(Paused:true). The scenario is: Time         Success description 10:50:00,1    Queuepause(Agent: Agent/5076, Paused:true) 10:50:00,2   Queuepause conf. Success [Interface paused successfully] 10:50:00,3    Evt Link Privilege[call,all] Channel1[Zap/3-1]Channel2 [Agent/5076] I suspect that the synchronization between agent state change and the queue calls isn't correct. Thank you
Comments:	By: Tristan Mahe (tristan_mahe) 2007-05-31 04:12:25 Hi, I'm having the same trouble, but using Local channels as dynamic members of a queue. Zap Local channel dials via a Zap trunk, I'm using autofill=yes, and when I have many customers in queue, app_queue tries to ring the same member many times, even he had answered one call. If you need more details, tell me, I'll provide logs and parts of dialplan. By: dmb (dmb) 2007-05-31 05:08:20 Hello, my agents are logged dinamically, too. By: Jason Parker (jparker) 2007-06-29 15:59:03 As far as I can tell, it checks the paused state, then immediately starts the process of setting up channels to call the user.  The paused status is being checked before the manager event is sent/processed - it just takes a short amount of time to setup a new call.  It seems very silly to check whether the queue member is paused, AFTER starting to setup the channel to call them. It doesn't appear to me that this is a real issue. By: dmb (dmb) 2007-07-30 09:56:39 I think that if the Queuepause confirmation is ok the call musn't delivered to that agent. By: Jason Parker (jparker) 2007-07-31 14:27:09 Again - we check the paused state, and then immediately start setting up the call.  The manager event is being processed DURING the call setup, AFTER we've already checked that the member is unpaused. There are two things I can see us doing here. 1) Do nothing. 2) Lock the entire queue in every place we call ring_one so that we sit in set_member_paused until the call is finished.  The problem with this is that not only does your manager event take a long time to finish, but nothing else can be done on that queue at the same time. By: Jason Parker (jparker) 2007-08-06 18:04:15 Closing, per my previous comments.