app_queue: Allow queue strategy to be manipulated externally.

[InterLinked1]

This adds the concept of "queue strategy providers" to interface with app_queue, which allows queue strategy logic to be implemented external to app_queue. This adds some simple hooks to app_queue to facilitate this, so that all other logic can be done in a separate module that registers with app_queue.

Resolves: #685

[InterLinked1]

cherry-pick-to: 18
cherry-pick-to: 20
cherry-pick-to: 21

[jcolp]

This feels like and looks like an implementation to fit your specific needs scoped specifically for that. For example:

1. Only a single strategy provider is supported
2. Since only a single strategy provider is supported, no configuration on a per-queue basis for it
3. No ability by the provider to store state

I require other people to provide input on this as to whether it is something they would use and meets their own needs before further reviewing for inclusion. If input is not received from others, I will not accept this.

[InterLinked1]

This feels like and looks like an implementation to fit your specific needs scoped specifically for that. For example:

1. Only a single strategy provider is supported
2. Since only a single strategy provider is supported, no configuration on a per-queue basis for it

Per your recommendation, I tried to simplify the changes in app_queue as much as possible with the idea that this sort of thing could be handled in the other module, to avoid adding complexity in app_queue itself. The other module could support multiple other mechanisms, etc. Would you prefer that all be handled in app_queue directly?

3. No ability by the provider to store state

What do you mean by the provider storing state, exactly? The state would be in the other module, no?

[jcolp]

And it would be associated to queues and callers... how?

My requirement still stands regardless.

[sboily]

Interesting, do you think it's possible to implement another strategy like skills based routing. We have an old patch for that and if it possible to switch it as a module instead of patching Asterisk it could be great for the maintenance and distribution.

[InterLinked1]

Interesting, do you think it's possible to implement another strategy like skills based routing. We have an old patch for that and if it possible to switch it as a module instead of patching Asterisk it could be great for the maintenance and distribution.

Yeah, the idea would be that things like that can be facilitated "externally" - so that could be implemented in or interact with the external strategy module. The idea is to make that kind of thing easier by having a defined mechanism for custom stuff so app_queue doesn't need to be patched anymore to do that stuff.

This patch does not aim to implement any strategy itself, but do you think the info exposed would facilitate implementing the strategy you have in mind?

[sboily]

Interesting, do you think it's possible to implement another strategy like skills based routing. We have an old patch for that and if it possible to switch it as a module instead of patching Asterisk it could be great for the maintenance and distribution.

Yeah, the idea would be that things like that can be facilitated "externally" - so that could be implemented in or interact with the external strategy module. The idea is to make that kind of thing easier by having a defined mechanism for custom stuff so app_queue doesn't need to be patched anymore to do that stuff.

This patch does not aim to implement any strategy itself, but do you think the info exposed would facilitate implementing the strategy you have in mind?

We discussed in 2011 to include this patch (https://github.com/wazo-platform/asterisk/blob/master/debian/patches/xivo_skill_queues) to Asterisk, but finally it was to big and nobody wanted to maintain it at Digium. Instead to have this patch we could convert it to a module for app_queue strategy and also probably easier to have more people in the community to use it easier. There is also some issue for linear strategy, you need to restart the module to apply it correctly, so maybe we this kind of feature we could create something. Another idea, AI based routing ;). I know the best way is to create your own queue with ARI, but it's quite long to reproduce all settings and for the moment it's not an option.

[InterLinked1]

Interesting, do you think it's possible to implement another strategy like skills based routing. We have an old patch for that and if it possible to switch it as a module instead of patching Asterisk it could be great for the maintenance and distribution.

Yeah, the idea would be that things like that can be facilitated "externally" - so that could be implemented in or interact with the external strategy module. The idea is to make that kind of thing easier by having a defined mechanism for custom stuff so app_queue doesn't need to be patched anymore to do that stuff.
This patch does not aim to implement any strategy itself, but do you think the info exposed would facilitate implementing the strategy you have in mind?

We discussed in 2011 to include this patch (https://github.com/wazo-platform/asterisk/blob/master/debian/patches/xivo_skill_queues) to Asterisk, but finally it was to big and nobody wanted to maintain it at Digium. Instead to have this patch we could convert it to a module for app_queue strategy and also probably easier to have more people in the community to use it easier. There is also some issue for linear strategy, you need to restart the module to apply it correctly, so maybe we this kind of feature we could create something. Another idea, AI based routing ;). I know the best way is to create your own queue with ARI, but it's quite long to reproduce all settings and for the moment it's not an option.

Yeah, that's exactly the motivation behind this patch - still use app_queue, but use your own algorithms for routing. So this is exactly the kind of thing it would aim to facilitate - skill based, AI, etc., and app_queue itself wouldn't need to be changed to do that.

The linear thing sounds like a separate bug, which this would not address.

[sboily]

The linear thing sounds like a separate bug, which this would not address.

Yes

[seanbright]

It looks like it would be straight-forward to have multiple external strategy providers that registered by name so that you can just use the standard strategy = my-external-strategy config.

That being said I would be interested in seeing an example external strategy implementation? Could you re-implement one of the existing strategies with it? I think that would be a useful demo.