|Summary:||ASTERISK-15536: [patch] app_queue: Give members a penalty time for not answering|
|Reporter:||Håkon Nessjøen (haakon)||Labels:||patch|
|Date Opened:||2010-01-27 19:05:05.000-0600||Date Closed:|
|Environment:||Attachments:||( 0) app_queue_1_8_2_2.c.new|
( 1) app_queue.c.new.patch
( 2) app_queue.c.patch
( 3) noanswer_penalty_13.patch
|Description:||This patch adds a new option notpresent-penalty option on queues.conf, which sets how many seconds of penalty a member will get for not answering in time.|
Say you have a queue with current setup:
If both member1 and member2 have left their phones, and forgot to log out, a normal queue would loop between these two users, trying to get them to answer. With this patch, they will be given a penalty when they don't answer, and so the queue will go to the next penalty level if neither member1 or member2 is answering their calls.
|Comments:||By: Leif Madsen (lmadsen) 2010-01-28 09:49:44.000-0600|
I've never used penalties, so have never run into this, but if what you're saying is true, this is a cool patch! Thanks!
By: Håkon Nessjøen (haakon) 2010-01-28 10:01:40.000-0600
It's also useful so you don't "hammer" a phone with calls, when the user obviously isn't there ;P
By: Håkon Nessjøen (haakon) 2010-01-28 16:34:03.000-0600
New patch uploaded. The first version didn't fully work as explained/expected. And updated to follow coding guidelines more closely.
Also added information to 'show queue xx':
myqueue (SIP/1001) with penalty 1 (realtime) (Not in use) has taken 2 calls (last was 2136 secs ago)
myqueue (SIP/1000) (not present: -29s) (realtime) (Not in use) has taken 1 calls (last was 2198 secs ago)
Where you see SIP/1000 is ignored for 29 seconds, and counting down, because he didn't answer.
By: Grzegorz Garlewicz (garlew) 2010-02-02 02:05:55.000-0600
Isn't it better to just use the autopause option which is already available?
By: Håkon Nessjøen (haakon) 2010-02-02 02:15:38.000-0600
Autopause leaves the member paused until you do something
By: Atis Lezdins (atis) 2010-02-02 05:38:13.000-0600
I would recommend using next_wrapuptime patch by eliel (not sure if it's already merged), as that would do exactly the same. It would allow You to set wrapuptime (delay) just for next call.
By: Håkon Nessjøen (haakon) 2010-02-02 05:45:20.000-0600
I don't see how this relates?
(next_)wrapuptime is after a person has answered a call?
This new feature is after a person has _not_ answered a call.
By: Atis Lezdins (atis) 2010-02-02 05:53:34.000-0600
Well, the point is that You can set it to any arbitrary number of seconds. So, You can basically do anything from dialplan (delay for some seconds), etc, etc..
I would rather see next_wrapuptime which allows much more flexibility rather than this specific patch
By: Håkon Nessjøen (haakon) 2010-02-02 06:07:36.000-0600
From the dialplan? I don't think you understand how this patch works.
The idea here is that the member of a queue is "removed" from the queue for a number of seconds because he didn't answer the phone.. This way the queue can automatically go to other priorities(read: penalties) of the members for some time. And then try again first after a given amount of time, to give the member another try.
You can't from the dialplan know when a member has not answered his phone and do anything specific for that member.
To say it in other words: This function has no relation to wrapuptime, since this is in regards to someone not answering, not someone hanging up after a successful call (which is what wrapuptime is for).
Please tell me how the next_wrapuptime would solve my problem, if you still mean so.
By: Leif Madsen (lmadsen) 2010-02-02 08:55:44.000-0600
From my viewpoint the suggestions made here to not require this patch are incorrect as I can't see how they allow the same functionality that is being implemented here to be utilized.
By: Håkon Nessjøen (haakon) 2010-02-24 03:52:42.000-0600
Any testers around to test this feature?
By: Leif Madsen (lmadsen) 2010-02-24 10:12:33.000-0600
I'd suggest you try and get some testers from the asterisk-user and/or asterisk-dev lists. Due to the amount of issues in the tracker, it is likely to get missed easily!
By: jazzy (jazzy) 2010-06-09 14:59:43
Haakon, I think you can do the same thing by utilizing queue rules.
Just set QUEUE_MIN_PENALTY and QUEUE_MAX_PENALTY in your dialplan and then increment them using rules in queuerules.conf.
By: Håkon Nessjøen (haakon) 2010-06-09 15:55:04
This patch is actually for two things. one thing helping the other.
One thing is the event I explained, where two agents with same penalty are not answering, and the queue keeps calling them, but the other is that the agents should not be called again for x seconds.
A lot of our users wants the phone to "give up" if an agent has forgot his phone logged in, while he's out of the office. With this patch, an agent can be ignored for x seconds for not answering in time. So I don't think QUEUE_MIN/MAX_PENALTY would do the same thing.
By: jazzy (jazzy) 2010-06-10 02:20:41
I understand the purpose of your patch. I'll try to explain my point. Consider the following configuration:
exten => somext,1,Set(QUEUE_MIN_PENALTY=1)
exten => somext,n,Set(QUEUE_MAX_PENALTY=2)
exten => somext,n,Queue(myqueue,,,,60)
exten => somext,n,Hangup()
defaultrule = myrule
member => SIP/1001,1
member => SIP/1002,1
member => SIP/1003,2
penaltychange => 30,,+1
Wouldn't it behave the similar way?
By: Håkon Nessjøen (haakon) 2010-06-10 03:09:07
As far as I can understand, what you are doing is relative to the caller, not to the queue. So if there is 10 callers. They all wait 30 seconds from when _they_ came to the queue, which can be any time.
My patch is relative to the member. The member should not get any calls at all for f.ex. 30 seconds. Also, is queuerules available with realtime?
By: Fernando Lara Campos (flarac) 2010-09-11 09:06:42
I test it on 220.127.116.11 an work fine.
I had the problem that if only I had a user in the priority 1 and this did not answer, the system does not jump to the next priority which had more users. With this patch fix it.
Before this patch try to use what is suggested in queuerules.conf but the system kept trying to pass the call to the agent who did not respond to priority one.
At this moment I have this patch running in production in conjunction with queuerules to achieve the expected behavior.
By: Håkon Nessjøen (haakon) 2010-09-13 05:08:10
flarac: In conjunction with queuerules? What have you added in queuerules? This patch should not need any changes of queuerules to do the behaviour you mentioned/wanted. Thanks for testing!
By: Håkon Nessjøen (haakon) 2010-09-13 08:26:40
Added reviewboard request.
By: Fernando Lara Campos (flarac) 2010-10-05 10:15:20
But i have two or tree types of users, and only want to ring them when passed 1 minute.
By: Fernando Lara Campos (flarac) 2011-02-07 10:28:10.000-0600
I just upload the update of this case for the version 1.8.2
By: Håkon Nessjøen (haakon) 2011-02-08 08:38:32.000-0600
Why did you upload this? The patch in the reviewboard is still working on latest trunk.
I would greatly appreciate if more people would test this feature, using the diff from the reviewboard and give their confirmation about this being a nice-to-have feature, so we could get it committed :)
By: Fernando Lara Campos (flarac) 2011-02-08 10:05:25.000-0600
Becouse the diff do not work on version 1.6.3 or 1.8.x.
And because they also think that this modification can be very useful to CallCenters
By: Chris James (cjames) 2013-01-10 04:29:12.201-0600
This is working well for me. The only downside is that if an agent is on a call, this puts them into the penalty state so when the call ends, the next call in the queue only rings after the penalty length has ended, not after the ACW time has ended
By: Marek Cervenka (cervajs) 2016-12-20 09:48:24.666-0600
is there somebody who ported it to asterisk 13? tnx
By: Martin Tomec (matesstar) 2016-12-30 09:35:17.230-0600
I have ported this patch to version 13 - patch is attached. With minor changes - agent is not marked as "not answering" when he is busy and autopausebusy is not set in config.
It is not submited to gerrit for review, because it is new functionality and without tests. So it would not be probably accepted.
By: Joshua Elson (joshelson) 2016-12-31 13:05:55.373-0600
This is useful functionality and could be at least added to 14 and master, I would think.
Has anyone tested this with realtime?