<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 9, 2015 at 4:17 PM, Leandro Dardini <span dir="ltr"><<a href="mailto:ldardini@gmail.com" target="_blank">ldardini@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I am back to try to fight with the problem highlighted few years ago <a href="https://issues.asterisk.org/jira/browse/ASTERISK-18480" target="_blank">https://issues.asterisk.org/jira/browse/ASTERISK-18480</a><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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 </div><div><br></div><div>find_load_queue_rt_friendly(const char *queuename) </div><div><br></div><div>instead of </div><div><br></div><div>member_config = ast_load_realtime_multientry("queue_members", "interface LIKE", "%", "queue_name", queuename, SENTINEL);<br></div><div><br></div><div>we can use something like </div><div><br></div><div><div>member_config = ast_load_realtime_multientry("queue_members", "interface LIKE", "%", "queue_name", queuename, SENTINEL, member_order, SENTINEL);<br></div></div><div><br></div><div>with member_order to contain the ordering of the members</div><div><br></div><div>obviously all functions and subsequent structures need to be changed to accept the new format</div><div><br></div><div>Do you think it is doable? will such change be accepted? do you think there can be a better way?</div></div></blockquote><div><br></div><div>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].<br><br></div><div>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.<br><br></div><div>That aside: I'm not sure I'd modify the linear ring strategy. Doing that feels bad for a few reasons:<br></div><div>(1) It impacts existing code more than necessary.<br></div><div>(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.<br><br></div><div>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.<br><br></div><div>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.<br><br></div><div>Matt<br></div></div><br>-- <br><div><div dir="ltr"><div>Matthew Jordan<br></div><div>Digium, Inc. | Engineering Manager</div><div>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA</div><div>Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a></div></div></div>
</div></div>