Hello to all, I read many posts about a specific situation and issue that happen since 2011 in this community and others. Basically I have a scenario that need to ring some Endpoints sequential and then repeat the ring looping.
It should be the “linear” strategy of Queue app, and work with this not using Realtime, but this option doesn’t work with Asterisk in Realtime, when we add the sequence order it works well, but when the Asterisk is restarted the sequence is lost.
With this scenario I am trying to solve the situation using strategy “ringall” with penalties applies and queue_rules. I setup the Queues with the pictures bellow:
I made these settings but is not working just is ringing the first Endpoint “PJSIP/19001003” with the penalty 1… after 30 seconds the queue rule is not changing to “PJSIP/11001015”.
I’m not convinced that this is to do with realtime.
Asterisk will only re-evaluate penalties when there is a timeout on calling an agent. It won’t cancel a call just because the agent ceased to be eligible. That could result in undesirable behaviour, like ringing an agent for just one second.
Also, the bug report quoted contains a statement:
That field is a Primary Key, so the result from any MySQL command is returned ordered by that field.
Relational database won’t guarantee a particular return order unless there is an explicit ORDER BY. Otherwise they are free to choose whatever is the most efficient processing order. Often that is primary key order, but they might, for example, satisfy a query from the contents of a secondary index.
Ordering by a unique ID field will give you a repeatable result, but I don’t think that there is any guarantee that that will correspond to the order in which records were added.
Those comment is not totally true, MySQL really order by primary as default, I tested already and when we change the PK the orders change too… but Asterisk is ordering by the field interface (PJSIP) always because it was defined in the code.
In the asterisk source code has an order by defined for the first field used in the query, then it is causing this trouble. This is my conclusion for now, I am deepening the analyzes.
The order by may well be an attempt to make the linear order work the way that people expected. The comment in the bug report seems to be assuming it works in member name order. The fact that it doesn’t may hint that there was no order by at that time.
Note that the apparently most efficient order may vary from database to database. E.g. without an order by, if you include a foreign key for queue_name, the database engine may choose between scanning the whole table, in primary key order, or seeking in the index on the foreign key and then pulling entries from the main table in the order in which they are listed in the secondary index. Which is chosen my depend on the sophistication of the query optimiser, the size of the table, the number of distinct queue names, when the query was compiled, and when the database statistics were last updated.
2021-07-22T14:53:07.932725Z 17667 Prepare SELECT * FROM queue_members WHERE interface LIKE ? AND queue_name LIKE ? ORDER BY interface
2021-07-22T14:53:07.932780Z 17667 Execute SELECT * FROM queue_members WHERE interface LIKE ‘%’ AND queue_name LIKE ‘%’ ORDER BY interface
There appears to be more than one version of the query, at least in as much as, for an update, the queue_name is included in the query.
(LIKE ‘%’ doesn’t seem to be very sensible SQL in any of the queries. At best it is ignored, at worst, it forces a a trivial pattern match on every record.)
It looks like the first field to match on is used as the order by, so the interface LIKE % is a fudge to cause the interface to be used for sorting:
