Summary:ASTERISK-16112: [patch] Autopause on busy issue
Reporter:jlpedrosa (jlpedrosa)Labels:
Date Opened:2010-05-18 08:46:57Date Closed:2011-09-28 12:07:40
Versions:Frequency of
Environment:Attachments:( 0) autopause_onbusy_when_rininguse.diff
( 1) autopausebusy.txt
Description:Hi all

I'm having agents DND buttons and not being paused.

As disscussed here: https://issues.asterisk.org/view.php?id=14376
acording to:
mmichelson: "Good observations, ringinuse=no is not 100% safe, especially in that DND scenario."

I think a condition depending on ringinuse status to force pause would be a good idea.

I can provide a patch if you think it may proceed.

Comments:By: Leif Madsen (lmadsen) 2010-05-18 10:46:51

As this is a feature request you will need to provide the patch you have offered to create. Thanks!

By: jlpedrosa (jlpedrosa) 2010-05-18 10:55:41

So i may assume you think this patch would proceed and make sense?

By: Paul Belanger (pabelanger) 2010-05-18 11:03:56

The issue tracker is not the best place to discuss features.  You'll get more response from #asterisk-dev on IRC or mailing lists.

By: jlpedrosa (jlpedrosa) 2010-05-19 04:05:40

Here is the patch, I've tested when ringinuse=no.

By: Leif Madsen (lmadsen) 2010-05-19 09:12:02

Did you forget to attach it? :)

By: jlpedrosa (jlpedrosa) 2010-05-19 09:18:34

...... Sorry, here it is.

By: Paul Belanger (pabelanger) 2010-05-19 10:51:50

Thanks for the patch. My only question is this a bug, or feature?  If a feature should we not create a setting for the user to control?

By: jlpedrosa (jlpedrosa) 2010-05-19 10:57:29

I my opinion it's half the way, since ir 'reusues' the ringinuse field to correct the Behavior.

I'll try to explain my thought:
How could a member respond Busy to asterisk? since asterisk knows the state of the peers and is the field rininuse=no (don't send calls to members in use).

In fact this was the orginal work mode (always pausing) until the issue on the header.

Should I send it to thre review board?

By: Leif Madsen (lmadsen) 2010-06-03 11:46:44

Not at this time -- don't worry about sending this to the reviewboard. Thanks!

By: Terry Wilson (twilson) 2011-08-24 17:56:16.155-0500

I'm reviewing this patch and I am having trouble understanding the situation that requires it. On an AST_CONTROL_BUSY, this patch would cause a member to be paused if autopause is set. It seems like it was a purposeful change to ensure that a member would only be paused on a "no answer" as in when someone had walked away from their desk. Making someone unpause themselves just because they were on another call doesn't make any sense to me. Can you explain why this would be preferable?

By: jlpedrosa (jlpedrosa) 2011-08-26 05:01:55.602-0500

Hi Terry

Here is the explanation:
Let's assume we're using a queue in a call center, an agent just needs to setup Do not disturb feature in the phone to just don't answer any call (or just reject it) or even just call VoiceMail and loop to be "busy". As you may understand this was a huge problem to managers in call center/project.

As asterisk don't send any call to an agent if it's really busy in a queue call, this patch makes asterisk behave exactly as we thought it was the correct way.

In fact, we changed this a couple of weeks after asterisk deployment because we found out this was happening.

Please let me know what you think.

By: Terry Wilson (twilson) 2011-08-29 10:47:15.919-0500

It seems much worse to me to autopause when we get a busy response. There is no way for the person who was called to know whether or not they may have gotten another call that returned busy while they were on the phone, so they would have to unpause themselves manually after every call just to be sure.

I could maybe see adding an autopausebusy configuration option so people could decide for themselves. It just seems strange to me that someone would ever want that behavior.

By: jlpedrosa (jlpedrosa) 2011-08-29 11:25:42.319-0500

Hi Terry

I gess it depends on the scenario, in our call center, agents are not allowed to call, just receive incoming calls, so it was absolutely necesary.

I guess there are other possible situation in which an agent is receiving and sending calls in the same logical line. Anyway asterisk if gets a busy will retry calling to that agent.

So the conclusion I'd say it the same, config must be able to handle both situations.

As there is other patch provided by me, wich adds a third option to autopause (in all queues agent is logged or just in the one that queue where timeout took place) adding other option to ringinuse sounds good to me, like 'yes, no, allways'

But I think this beahavior is mandaory for a call center.

Best regards

By: Terry Wilson (twilson) 2011-08-29 13:22:18.484-0500

Please try the autopausebusy.txt patch and set autopausebusy=yes in queues.conf for the queues that you want this behavior on.

I can't change the behavior for everyone, but this should allow you do what you need to do. I haven't tested it, but it is a very simple patch (for Asterisk 1.10).

Since this would be a new feature (as 1.8 has *always* been this way since the behavior changed in 1.6.x), the earliest release this feature would be in would be 1.10.

By: jlpedrosa (jlpedrosa) 2011-08-29 16:03:11.262-0500

Hi Terry!

If I've understand your code correctly, you want to add a new boolean parameter called 'autopausebusy' with default to 'no' so the default behaviour is the old one: won't be paused if busy.

I left the company in wich this Call center was installed, so I can't test this, but it looks good to me also.

For sure this aproach is simpler in code than adding other option to ringuse.

Just a small thing:
you've declared
unsigned int autopausebusy:1;
if on queues.conf you delete or comment ";autopausebusy=no"
you really won't get the 'default' behaviour, because autopausebusy will be 1 and in queues.conf you say default value will be 'no'.

Thanks for your help

By: Terry Wilson (twilson) 2011-08-29 16:47:05.847-0500

:1 just means that it is a bitfield requiring only one bit. See http://en.wikipedia.org/wiki/C_syntax#Bit_fields for an example. Thanks for taking a look at it. I'll go ahead and post this for review and get it committed, then.