Queue strategy “Linear” with Asterisk 20 on Realtime

Asterisk Asterisk Support
1

This issue has already been reported in other versions; I myself had already reported it in version 16 here, and it seems that it has not yet been fixed in version 20 or I am not knowing how to configure it.

I am creating the queues using realtime with PostgreSQL database.

SELECT * FROM public.queue_members ORDER BY uniqueid ;
 queue_name | interface  | membername | state_interface  | penalty | paused | uniqueid | wrapuptime | ringinuse
------------+------------+------------+------------------+---------+--------+----------+------------+-----------
 demo       | PJSIP/4001 |            | hit:4001@default |         |      0 |        1 |            |
 demo       | PJSIP/2000 |            | hit:2000@default |         |      0 |        2 |            |
 demo       | PJSIP/4000 |            | hit:4000@default |         |      0 |        3 |            |
(3 rows)

I am defining the order in which extensions should be called based on the uniqueid column of the queue_members table. However, regardless of the order I specify or the order in which I perform the INSERT operations, Asterisk always sorts based on the interface column:

CLI> queue show
demo has 0 calls (max unlimited) in 'linear' strategy (0s holdtime, 0s talktime), W:0, C:0, A:0, SL:0.0%, SL2:0.0% within 0s
   Members:
      PJSIP/2000 (ringinuse disabled) (realtime) (Invalid) has taken no calls yet (login was 1191 secs ago)
      PJSIP/4000 (ringinuse disabled) (realtime) (Invalid) has taken no calls yet (login was 1191 secs ago)
      PJSIP/4001 (ringinuse disabled) (realtime) (Invalid) has taken no calls yet (login was 1191 secs ago)
   No Callers

I am using the Debian 13 operating system, PostgreSQL 13.11, and Asterisk 20.1.0.

Please, could someone inform me if I am doing something wrong or if it is still pending correction by the Asterisk developers?

2

Nothing has changed.

3

The issue tracker mentions that it affects version 16.
Should I create a new one stating that version 20 is affected, considering that version 16 no longer receives updates due to being in Security Fix Only mode?

Another reason is that there is a message on the JIRA page:

This JIRA is now in a read-only state, as is the Gerrit server. Asterisk now lives on Github at GitHub - asterisk/asterisk: The official Asterisk Project repository.. No issues or patches have been copied to Github.

Perhaps they are not aware of or do not remember this issue anymore.

Is it recommended that I report this issue at The Asterisk Project · GitHub?

4

You can report an issue on GitHub if you wish. I honestly doubt anyone will look into it in the end, but perhaps someone will.

5

Thank you for the honest feedback. I have reported the bug there. We have been using Asterisk with a database since version 1.6, and we have been gradually migrating to realtime since version 13. This seems to be the only option that is still not working correctly in the queues.

6

Hello Celsoannes,

I was just wondering why you do not use the agent penalty option to get the order in which you want the extensions to be called…?

I am sure that works.

7

I tested your suggestion and it worked partially.
It respects the value defined in penalty and starts calling the member with the lowest penalty.
However, it only calls this member without calling the others.

SELECT name, musiconhold, timeout, ringinuse,  retry, strategy FROM public.queues;
 name | musiconhold | timeout | ringinuse | retry | strategy
------+-------------+---------+-----------+-------+----------
 demo | default     |      12 | no        |     2 | linear

SELECT * FROM public.queue_members ORDER BY penalty;
 queue_name | interface  | membername |  state_interface  | penalty | paused | ramal | uniqueid | wrapuptime
------------+------------+------------+-------------------+---------+--------+-------+----------+------------
 demo       | PJSIP/4001 |            | hint:4001@default |       1 |      0 | 4001  |        1 |
 demo       | PJSIP/4000 |            | hint:4000@default |       2 |      0 | 4000  |        2 |
 demo       | PJSIP/2000 |            | hint:2000@default |       3 |      0 | 2000  |        3 |

demo has 0 calls (max unlimited) in 'linear' strategy (19s holdtime, 1s talktime), W:0, C:9, A:3, SL:0.0%, SL2:0.0% within 0s
   Members:
      PJSIP/2000 with penalty 3 (ringinuse disabled) (realtime) (Not in use) has taken 3 calls (last was 4787 secs ago) (login was 5875 secs ago)
      PJSIP/4000 with penalty 2 (ringinuse disabled) (realtime) (Not in use) has taken no calls yet (login was 5875 secs ago)
      PJSIP/4001 with penalty 1 (ringinuse disabled) (realtime) (Not in use) has taken 6 calls (last was 290 secs ago) (login was 5875 secs ago)
   No Callers

In the test, it keeps calling only extension 4001 instead of switching to the others when it reaches the ring limit defined in the timeout.

[2023-06-29 09:45:46]     -- Executing [1000@sandbox:1] Answer("Console/default", "") in new stack
[2023-06-29 09:45:46]   --- <("<) --- Call from Console has been Answered --- (>")> ---
[2023-06-29 09:45:47]     -- Executing [1000@sandbox:2] Queue("Console/default", "demo") in new stack
[2023-06-29 09:45:47]     -- Started music on hold, class 'default', on channel 'Console/default'
[2023-06-29 09:45:47]     -- Called PJSIP/4001
[2023-06-29 09:45:47]   == Using SIP RTP Audio TOS bits 184
[2023-06-29 09:45:47] WARNING[769901][C-0000000c]: chan_console.c:651 console_indicate: Don't know how to display condition 22 on Console/default
[2023-06-29 09:45:47]     -- PJSIP/4001-00000015 is ringing
[2023-06-29 09:45:47]   == Manager 'asterisk' logged on from 127.0.0.1
[2023-06-29 09:45:59]     -- Nobody picked up in 12000 ms
[2023-06-29 09:46:01]     -- Called PJSIP/4001
[2023-06-29 09:46:01]   == Using SIP RTP Audio TOS bits 184
[2023-06-29 09:46:01]     -- PJSIP/4001-00000016 is ringing
[2023-06-29 09:46:13]     -- Nobody picked up in 12000 ms
[2023-06-29 09:46:15]     -- Called PJSIP/4001
[2023-06-29 09:46:15]   == Using SIP RTP Audio TOS bits 184
[2023-06-29 09:46:15]     -- PJSIP/4001-00000017 is ringing
[2023-06-29 09:46:27]     -- Nobody picked up in 12000 ms
[2023-06-29 09:46:29]     -- Called PJSIP/4001
[2023-06-29 09:46:29]   == Using SIP RTP Audio TOS bits 184
[2023-06-29 09:46:29]     -- PJSIP/4001-00000018 is ringing
bruce*CLI> console hangup
[2023-06-29 09:46:33]     -- Stopped music on hold on Console/default
[2023-06-29 09:46:33]   == Spawn extension (sandbox, 1000, 2) exited non-zero on 'Console/default'
[2023-06-29 09:46:33]   --- <("<) --- Hangup on Console --- (>")> ---
8

But then you have to make sure that the agent is set to unavailable when the agent does not answer an offered call…

As the caller is placed back in the queue and then the first agent, with the lowest penalty, is called again.

You will have to set the agent on pause, or log them out of the queue, when they do not answer a call.

9

Have a look at: The queues.conf File
I know old edtion…

queues.conf:

autopause yes, no, all Enables/disables the automatic pausing of members who fail to answer a call. A value of all causes this member to be paused in all queues she is a member of.

10

In this case, your suggestion will not solve the problem because I need it to ring the next extension if the current one doesn’t answer, and once it finishes ringing the last extension, it should go back to ringing the first one. The way it was suggested, if the call completes a cycle, it will not ring any other agent until they return to the queue or remove the pause from their extension.

11

Ok, got it…
Then you will have to find another method…

Maybe work with failover queues…

12

@meightee
Thank you for the suggestions, I already use failover in some circumstances. However, in this case, besides losing the queue statistics, I would have to do a workaround to reach the desired flow, creating loops and counters along the way.

13

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.