Ticket #2481 (new Feature Requests)

Opened 6 years ago

Last modified 4 years ago

Cyclic Hunting Support in Ring Groups

Reported by: Nick_Lewis Assigned to: p_lindheimer
Priority: minor Milestone: Undetermined
Component: Ring Groups Version:
Keywords: Cc:
Confirmation: Confirmed Distro:
Backend Engine: All Distro Ver:
Backend Ver: SVN Revision (if applicable):

Description

In some environments there is a need to even out the number of calls taken by each member of a ring group. Examples include technical support helplines (to even the loading) and sales hotlines (to even the leads). This can be acheived by adding a cyclic hunting mode. Instead of starting each call at the same position in the hunting group, calls start at a position that cycles through the members of the ring group. e.g.

call_1 -> rg_member1 -> rg_member2 -> rg_member3 -> rg_member1

call_2 -> rg_member2 -> rg_member3 -> rg_member1 -> rg_member2

call_3 -> rg_member3 -> rg_member1 -> rg_member2 -> rg_member3

call_4 -> rg_member1 -> rg_member2 -> rg_member3 -> rg_member1

This can be acheived with a global dialplan variable for each ringgroup which stores the current start position.

Attached is a rough implementation

Attachments

functions.inc.php (9.9 kB) - added by Nick_Lewis on 11/07/07 07:07:44.
page.ringgroups.php (16.5 kB) - added by Nick_Lewis on 11/07/07 07:09:20.
diffile.txt (5.6 kB) - added by Nick_Lewis on 07/07/08 06:09:19.
ticket2481.patch (5.6 kB) - added by Nick_Lewis on 07/07/08 10:03:43.

Change History

11/07/07 07:07:44 changed by Nick_Lewis

  • attachment functions.inc.php added.

11/07/07 07:09:20 changed by Nick_Lewis

  • attachment page.ringgroups.php added.

11/07/07 09:51:29 changed by p_lindheimer

  • confirmation changed from Unreviewed to Confirmed.
  • component changed from - choose - to Ring Groups Module.
  • version deleted.

would probably use AstDB() to do such to be consistent with other features as we move more things over to be more dynamic. Thanks for the input, in the future it is more useful to supply such suggestions as a patch file instead of the entire files.

11/07/07 10:50:48 changed by Nick_Lewis

Ok I will look into using AstDB() instead of dialplan globals. If I work out how to do this and how to make a suitable patch file I will send it to you for your consideration

Best Regards Nick

11/28/07 02:27:19 changed by p_lindheimer

  • milestone changed from 2.4 to 3.0.

07/05/08 17:17:57 changed by mbrevda

Nick_Lewis: thanks for the patch! If you would please reattach it in diff format - that would enable he dev's to quickly spot the changes. Thanks again

07/07/08 06:09:19 changed by Nick_Lewis

  • attachment diffile.txt added.

07/07/08 06:10:28 changed by Nick_Lewis

I made the original cyclic ringgroup changes on 2.2 so I have now tried to reimplement them on 2.5 and produce a diff file. The original 2.2 version has had lots of testing but this one has not.

07/07/08 06:43:15 changed by mbrevda

Phillipe? (i'm leaving this one to you)

07/07/08 09:19:18 changed by p_lindheimer

Nick can you attach these with a .diff or .patch name so the trac viewer brings them up properly? thanks.

Now one comment although I'm barely awake this morning. This looks like there is a race condition potential. It may not have any bad consequences beyond a hiccup in the cycle but is should still probably be addressed. There is a call (which would need to be added to the extensions class), MacroExclusive?(), that could be used to avoid the race condition although it is an Asterisk 1.4+ feature only which is also problematic.

07/07/08 10:03:43 changed by Nick_Lewis

  • attachment ticket2481.patch added.

07/07/08 10:09:10 changed by Nick_Lewis

Phillipe

I have renamed the patch and attached it again.

Can you please explain the details of the race condition so that I may better understand it.

07/07/08 10:19:12 changed by p_lindheimer

the race conditon is that that 2 simultaneous calls to the same ringgroup are accessing and manipulating the same global variable at the same time. But as mentioned, I have not really studied the change.

However - I'd also prefer to see something like this change move all of the ringgroup ring lists into astdb (like findmefollow does) and then dialparties.agi can handle the changes as well as this would provide the infrastructure to enable things like dynamic agents to ringgroups and programs outside of freepbx able to manipulate the groups (such as an xml application).

07/07/08 10:53:23 changed by Nick_Lewis

Phillipe

I am hopeful that the race condition is well bounded since each call manipulates only a local copy of the global variable. There is a short time between reading the global and writing the manipulated local back to the global but during this time the position in the cycle will be simply replicated to all simultaneous calls. Since the extension at the head of ringgroup will be busy the normal ringgroup action will be followed which will appear to the user as though cycling is operating correctly. However after the race condition has ceased, the cyclic pointer will not have incremented by the number calls required so there will be a bit of apparent rewind. This rewind is not biased to any position in the cycle so will not advantage or disadvantage any particular user in the cyclic ringgroup.

It would be nice to have an AstDb? solution but the current implementation has been working well for my clients and I have not had time up to now to investigate converting it. I think that cyclic ringgroup support is a "must have" capability in sales and technical support environments so it may be worth having even without the improved implementation. YMMV

07/07/08 11:01:29 changed by p_lindheimer

I agree that the race condition is probably no more than a hiccup as indicated. I'd still really like to see something like this in AstDB and moving the manipulation into dialparties.agi (not that this provides any easier of a solution to the race condition), along with the rest of the ringgoup moving to astdb. Anyone want to take this on? It should just mean copying what followme did with a few tweaks?

07/24/08 23:50:49 changed by p_lindheimer

  • milestone changed from 2.5 to 3.0.

08/17/09 19:12:23 changed by p_lindheimer

  • milestone changed from 2.6 to 2.7.