Summary:	ASTERISK-07192: [patch][post 1.4] escalate over penalty if no one answers
Reporter:	dillec (dillec)	Labels:
Date Opened:	2006-06-16 19:21:35	Date Closed:	2007-01-07 15:32:43.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_queue
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) app_queue.c-add-escalate-if-not-available-third-review.patch
Description:	This patch will add the following configuration directive to queues.conf: escalate-if-not-available = yes/no If an queue member with higher priority is not answering the call, the penalty is switched off for the next run (This patch has ISSUE 0007382 merged since it does not work without) ****** ADDITIONAL INFORMATION ****** An example: [TestQ1] timeout = 8 escalate-if-not-available = yes member => SIP/test1,0 member => SIP/test2,1 member => SIP/test3,2 --> dialing "TestQ1" SIP/test1 --> timeout after 8 seconds SIP/test2 --> timeout after 8 seconds SIP/test3 --> timeout after 8 seconds start over [TestQ2] timeout = 8 escalate-if-not-available = no member => SIP/test1,0 member => SIP/test1,1 member => SIP/test1,2 SIP/test1 --> timeout after 8 seconds SIP/test1 --> timeout after 8 seconds SIP/test1 --> timeout after 8 seconds ... same behavior until call is canceled
Comments:	By: Serge Vecher (serge-v) 2006-06-19 09:45:45 please review the CODING GUIDELINES documents and fix up the patch accordingly: you have problems with indentation in many places, as well as trailing white-space. By: dillec (dillec) 2006-06-19 12:44:03 sorry, will change editor to something reliable asap. By: Serge Vecher (serge-v) 2006-06-19 12:58:50 looks better. Just one more comment -- no need for curly brackets in single-line if statements: - if (mem->penalty > qe->max_penalty) + if (mem->penalty > qe->max_penalty && qe->max_penalty) { return -1; + } By: dillec (dillec) 2006-06-19 14:05:22 ok. i've deleted the brackets. Code should be ok now :-) By: BJ Weschke (bweschke) 2006-06-21 22:37:23 there are also thread safety/mutex lock concerns with this change as there were with other patch I review from you. We can't be changing the structure of the call queue without making certain it's been locked first. By: dillec (dillec) 2006-06-23 01:18:32 ok, thanks for your comments!! same matter in 0007279: [patch][post 1.4] app_queue: linear strategy I will provide patches against trunk at weekend. By: dillec (dillec) 2006-06-25 12:02:17 reviewed once again and added locking to the struct. By: alric (alric) 2006-06-26 07:47:19 Great edition.  Can't wait to see it included. By: Russell Bryant (russell) 2006-07-16 15:37:40 What's wrong with just setting QUEUE_MAX_PENALTY to 0, have them enter the Queue, and if the call comes back out because of a timeout, you set QUEUE_MAX_PENALTY to 1 and put them back in the queue, and so on? By: dillec (dillec) 2006-07-17 14:33:11 thats a good point but it won't work on more than 2 simoultanous calls. I think there would be a high confusion about call distribution. Further more this version saves dialplan complexity. By: Jason Parker (jparker) 2006-07-17 16:02:25 What do you mean it won't work on more than 2 simultaneous calls? I'm gonna have to agree with Russell here.  There is no reason to add a feature to an app, which can easily be done via dialplan. By: Russell Bryant (russell) 2006-07-17 17:37:04 What I have described is exactly what we are doing on the Digium PBX and it is working great.  :) By: Jason Parker (jparker) 2006-07-17 17:40:30 Russell: and it only took 800km to get there... </injoke> By: dillec (dillec) 2006-07-18 15:56:31 your method: Call 1 comes in -> Agent 1 is ringing --> Call 2 comes in -> Agent 1 timeout (call 1) -> escelate -> Agent 1 rings (call 2) --> Timeout my method: Call 1 comes in -> Agent 1 is ringing --> Call 2 comes in -> Agent 1 timeout (call 1) -> escelate -> Agent __2__ rings (call 1 / call 2) The call is not distributed orderly from 1 to 2 (..) which would be senseless if the guy on agent 1 is not available. The call would always be stuck on him at the first time until timeout hits. Further more i would add 10*2 more Dialplan extensions only to go through member 1 to 10 which would make my dialplan with ONE of those queues complex. Imagine that there would be 10 or 20 of such queues. i don't know if that is better as adding this feature. By: jmls (jmls) 2006-10-31 14:16:04.000-0600 russell: Do you want to close this as you say it can be emulated in the dialplan ? By: jmls (jmls) 2007-01-07 03:07:21.000-0600 russell: Do you want to close this as you say it can be emulated in the dialplan ? By: Tilghman Lesher (tilghman) 2007-01-07 15:32:43.000-0600 I'm in agreement with russell.  The problem with the approach here is that the first queue member will never get any calls once excluded.  There would need to be a way for the first queue member to receive calls again for this method to be viable.