[Home]

Summary:ASTERISK-08344: [patch] Limit on simultaneous calls for queue members
Reporter:Richard Braun (rbraun_proformatique)Labels:
Date Opened:2006-12-13 07:06:45.000-0600Date Closed:2011-06-07 14:02:45
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/General
Versions:Frequency of
Occurrence
Related
Issues:
is related toASTERISK-15063 [patch] Limit on simultaneous incoming calls for queue members
Environment:Attachments:( 0) asterisk_app_queue_call_limit.patch
( 1) asterisk-1.2.13_queue_call_limit.patch
( 2) pf_queue_call_limit.patch
Description:The queue application doesn't allow limits on simultaneous calls for queue members. Some workarounds like call-limit in sip.conf cause many other problems (for example, calls can't be transfered if call-limit is 1). We (at Proformatique) have written a patch for app_queue which allows placing such a limit. queues.conf can then be configured as this :

member = SIP/100[,penalty[,call-limit]]

If call-limit isn't specified, it is 0. A call-limit of 0 means no limit. Thus, it shouldn't break any configuration (at least in the static conf file, I haven't tested RealTime configurations).
Comments:By: wes (whoiswes) 2006-12-13 08:03:38.000-0600

FYI:
two related issues:  http://bugs.digium.com/view.php?id=7433
http://bugs.digium.com/view.php?id=6315

By: Serge Vecher (serge-v) 2006-12-13 08:51:03.000-0600

Richard: thanks for the patch! As this is a new feature, it needs to be redone against trunk.

By: Leif Madsen (lmadsen) 2006-12-13 09:19:22.000-0600

I added the related issues that whoiswes mentioned.... although now that I've added them, I'm not entirely sure why they are related.

By: wes (whoiswes) 2006-12-13 13:21:06.000-0600

7433 is a devicestate issue - it MAY not apply to this particular patch as this code seems to be duplicating what the devicestate code is attempting to do...in any case, 7433 was originally opened to alleviate issues with queues sending multiple calls.

6315 is an alternate version of the queue-call-limit idea, and it utilizes devicestate to track whether a device is on an active call or not.  the patch in 6315 was added to trunk a while back - it should not conflict with this patch, but they effectively are tackling the same problem.  

since 6315 is dependant on 7433 to work properly, i figured i'd add the note in case anyone wanted to delve into this issue further.  i have been following every queue-related bug for over a year now, specifically those related to the how app_queue sends calls to agents, because we utilize asterisk in our call center, and having agents with 6 active queue calls at once is not a good thing.

this patch looks to be an alternate way of doing exactly what bugs 6315 and 7433 are attempting to do - which is the better (or more correct) way  is yet to be seen.

By: Richard Braun (rbraun_proformatique) 2006-12-14 11:39:22.000-0600

Sorry, I'm afraid I won't have time to write a new patch against trunk soon. This patch was written essentially for our clients, and they all use Asterisk 1.2.

By: Leif Madsen (lmadsen) 2006-12-15 08:29:22.000-0600

Since new features can not go into 1.2, then we either need to determine which of the two approaches is more correct and determine if this patch is worth time by someone else to get into trunk (i.e. is the 'right' fix), or if we're going to use the other approaches in 7433 and 6315 instead.

Comments from developers?

By: Serge Vecher (serge-v) 2007-03-13 10:07:08

BJ: could you please make a final determination on the fate of this issue?

By: Igor Goncharovsky (igorg) 2007-05-03 22:07:38

I can spend some time to make this feature works for trunk, if this feature will 'right' fix. Also it is a fours parameter for a member. May be there are some reasons to make description of a member something like this:

[member_1]
interface=SIP/100
name=John
penalty=2
call_limit=1

By: BJ Weschke (bweschke) 2007-08-24 14:28:36

if you guys want to provide a valid patch for this in /trunk please let us know your intention to do so within a weeks time or we will close.

By: Richard Braun (rbraun_proformatique) 2007-08-27 08:17:36

We should indeed write a new version of the patch for trunk soon, please don't close.

By: BJ Weschke (bweschke) 2007-08-27 08:19:52

Ok. Thanks! We'll stand by for it!

By: Sylvain Boily (sboily_proformatique) 2007-08-27 09:04:27

For people who want to use this patch on latest asterisk 1.2.24, i have upload a new version. (pf_queue_call_limit.patch)

By: Richard Braun (rbraun_proformatique) 2007-09-06 04:37:05

A patch for trunk has just been uploaded. Reviews are welcome.

By: Ronald Chan (loloski) 2007-09-14 10:43:17

Any news here ? thanks

By: Tilghman Lesher (tilghman) 2007-11-06 17:15:05.000-0600

1.  Please don't add credits to source files.  If you want a credit, add it to the CREDITS file in the root directory.

2.  When adding new options to dialplan apps, please add them at the END of the argument list.  Otherwise, you break backwards compatibility.  (APIs are different, and rearrangement of those options is fine.)

3.  You are recycling the pausing.  It's clear that you're not using that, but queue members who are using that will be very confused if they pause themselves during a call (to take a bathroom break for instance) and are immediately unpaused when the call ends.  Please consider that a bug that needs to be fixed (i.e. you should only unpause a member, if their pausing was caused by the call-limit).

4.  Again, messing with string order in the astdb breaks upgrades.  Always add new options to the end.

5.  From a usability perspective, "call-limit" is difficult to type.  Please consider renaming the CLI keyword "limit".

By: Tilghman Lesher (tilghman) 2007-12-07 14:33:02.000-0600

No response from reporter.  Reopen if/when you can make the requested changes.