[asterisk-bugs] [JIRA] (ASTERISK-27017) Linear queue retries as many agents as were skipped

[Jared Hull (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-27017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jared Hull updated ASTERISK-27017:
----------------------------------

    Description: 
When using a linear queue, all agents are dialed in the order they are added to queues.conf. With the option 'n' added to the queue application, I would expect the queue to stop once it has reached the timeout of the last agent. It does this when all agents are (Not in use).

n - No retries on the timeout; will exit this application and go to the next step

Paused or unavailable agents (due to an unavailable contact status) will cause the queue to loop around to the first agent and ring as many agents as there were paused or unavailable before 'Exiting on time-out cycle'.

{quote}exten => 424242,1,Answer
same => n,Queue(linearQ,wxRn)
same => n(noAnswer),Busy{quote}

{quote}testbed*CLI> queue show
linearQ has 0 calls (max unlimited) in 'linear' strategy (0s holdtime, 0s talktime), W:0, C:0, A:0, SL:0.0% within 60s
   Members:
      PJSIP/109 (ringinuse enabled) (paused) (Not in use) has taken no calls yet
      PJSIP/100 (ringinuse enabled) (Unavailable) has taken no calls yet
      PJSIP/103 (ringinuse enabled) (Not in use) has taken no calls yet
      PJSIP/102 (ringinuse enabled) (Not in use) has taken no calls yet
   No Callers{quote}

The test case in log.txt, the order of agents and status is show above. the expected behaviour is that 103 and 102 would ring before the caller exits the queue to the next line in dialplan. Instead we see the queue loop around and dial both 103 and 102 again. If 109 was unpaused, it rings 109,103,102 and then loops around to 109 again because 100 is unavailable.

  was:
When using a linear queue, all agents are dialed in the order they are added to queues.conf. With the option 'n' added to the queue application, I would expect the queue to stop once it has reached the timeout of the last agent. It does this when all agents are (Not in use).

n - No retries on the timeout; will exit this application and go to the next step

Paused or unavailable agents (due to an unavailable contact status) will cause the queue to loop around to the first agent and ring as many agents as there were paused or unavailable before 'Exiting on time-out cycle'.

{quote}exten => 424242,1,Answer
same => n,Queue(linearQ,wxRn)
same => n(noAnswer),Busy{quote}

{quote}testbed*CLI> queue show
linearQ has 0 calls (max unlimited) in 'linear' strategy (0s holdtime, 0s talktime), W:0, C:0, A:0, SL:0.0% within 60s
   Members:
      PJSIP/109 (ringinuse enabled) (paused) (Not in use) has taken no calls yet
      PJSIP/100 (ringinuse enabled) (Unavailable) has taken no calls yet
      PJSIP/103 (ringinuse enabled) (Not in use) has taken no calls yet
      PJSIP/102 (ringinuse enabled) (Not in use) has taken no calls yet
   No Callers{quote}


> Linear queue retries as many agents as were skipped
> ---------------------------------------------------
>
>                 Key: ASTERISK-27017
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27017
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_queue
>    Affects Versions: 13.15.0
>            Reporter: Jared Hull
>         Attachments: log.txt, queues.conf.txt
>
>
> When using a linear queue, all agents are dialed in the order they are added to queues.conf. With the option 'n' added to the queue application, I would expect the queue to stop once it has reached the timeout of the last agent. It does this when all agents are (Not in use).
> n - No retries on the timeout; will exit this application and go to the next step
> Paused or unavailable agents (due to an unavailable contact status) will cause the queue to loop around to the first agent and ring as many agents as there were paused or unavailable before 'Exiting on time-out cycle'.
> {quote}exten => 424242,1,Answer
> same => n,Queue(linearQ,wxRn)
> same => n(noAnswer),Busy{quote}
> {quote}testbed*CLI> queue show
> linearQ has 0 calls (max unlimited) in 'linear' strategy (0s holdtime, 0s talktime), W:0, C:0, A:0, SL:0.0% within 60s
>    Members:
>       PJSIP/109 (ringinuse enabled) (paused) (Not in use) has taken no calls yet
>       PJSIP/100 (ringinuse enabled) (Unavailable) has taken no calls yet
>       PJSIP/103 (ringinuse enabled) (Not in use) has taken no calls yet
>       PJSIP/102 (ringinuse enabled) (Not in use) has taken no calls yet
>    No Callers{quote}
> The test case in log.txt, the order of agents and status is show above. the expected behaviour is that 103 and 102 would ring before the caller exits the queue to the next line in dialplan. Instead we see the queue loop around and dial both 103 and 102 again. If 109 was unpaused, it rings 109,103,102 and then loops around to 109 again because 100 is unavailable.



--
This message was sent by Atlassian JIRA
(v6.2#6252)