[asterisk-dev] Queue realtime and members ordering

[Matthew Jordan]

On Mon, Feb 9, 2015 at 4:17 PM, Leandro Dardini <ldardini at gmail.com> wrote:

> I am back to try to fight with the problem highlighted few years ago
> https://issues.asterisk.org/jira/browse/ASTERISK-18480
>
> In short, when using realtime queue members, it is impossible to use
> ordered ringing method because it is impossible to define the ordering of
> agents and the alphabetical ordering is used.
>
> I side stepped the problem by using custom member name like
> Local/AG-000-56 and Local/AG-001-23 and so on to make agent 56 to be ring
> before agent 23.
>
> Unfortunately this solution has the nasty problem of letting wrapuptime to
> not work across multiple queues when using the shared_lastcall. Member 56
> can be Local/AG-000-56 in one queue and Local/AG-002-56 in another queue.
>
> A solution can be to change the way ast_load_realtime_multientry works, by
> providing the ordering field, maybe adding a second SENTINEL item defining
> it, so in
>
> find_load_queue_rt_friendly(const char *queuename)
>
> instead of
>
> member_config = ast_load_realtime_multientry("queue_members", "interface
> LIKE", "%", "queue_name", queuename, SENTINEL);
>
> we can use something like
>
> member_config = ast_load_realtime_multientry("queue_members", "interface
> LIKE", "%", "queue_name", queuename, SENTINEL, member_order, SENTINEL);
>
> with member_order to contain the ordering of the members
>
> obviously all functions and subsequent structures need to be changed to
> accept the new format
>
> Do you think it is doable? will such change be accepted? do you think
> there can be a better way?
>

The problem you are always going to face when modifying app_queue is
ensuring that you haven't broken anything else. That means writing tests to
demonstrate the safety of the changes, and to help ensure that future
modifications don't break the improvements. Information on writing tests
for the Asterisk Test Suite can be found on the wiki [1].

If you are interested in going forward with this, I would highly suggest
discussing the tests needed for the change further, as a lot of
infrastructure has been added to the Test Suite to help with this,
including the ability to mock out Real Time using the cURL backend.

That aside: I'm not sure I'd modify the linear ring strategy. Doing that
feels bad for a few reasons:
(1) It impacts existing code more than necessary.
(2) The fact that something wants to ring members in some particular order
is independent of what determines the ordering. Statically defining that to
one field is more limiting than making the field that determines the
ordering dynamic.

Instead, I would try to solve the underlying cause of the issue: that there
is no way to tell Asterisk how to select the members from a RealTime
database. Unfortunately, that's not easy either. Currently, the realtime
backends use the first field of selection as the ORDER BY parameter.
There's no standard way to pass this down into
ast_load_realtime_multientry. This could be easily handled by using a
double SENTINEL delineated list of variable arguments, but would require
careful parsing in the realtime code and proper handling in all of the
realtime backends.

As an aside, this change would be a new feature/improvement. You would want
to develop this change against trunk as a start, which has some differences
in the RealTime API versus previous versions of Asterisk.

Matt

-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150211/9d687171/attachment.html>