[asterisk-bugs] [JIRA] (ASTERISK-29117) Zero wrapuptime is NOT respected in a ringall queue and no ringinuse
Ioannis Inglesis (JIRA)
noreply at issues.asterisk.org
Sat Oct 17 12:07:36 CDT 2020
[ https://issues.asterisk.org/jira/browse/ASTERISK-29117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=252477#comment-252477 ]
Ioannis Inglesis commented on ASTERISK-29117:
---------------------------------------------
I re-write the whole issue and tested against 16.13.0 which is the current release of asterisk 16. Still the same problem occurs.
> Zero wrapuptime is NOT respected in a ringall queue and no ringinuse
> --------------------------------------------------------------------
>
> Key: ASTERISK-29117
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-29117
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Applications/app_queue
> Affects Versions: 16.13.0
> Environment: Tested against Debian 9 - Stretch
> Reporter: Ioannis Inglesis
> Assignee: Unassigned
> Attachments: extensions.conf, queues.conf, sip.conf
>
>
> We a have a single queue that contains 2 members. Queue's configuration is with ringall strategy, 20 seconds timeout, no ringinuse and wrapuptime to 0.
> Scenario:
> * A first call arrives at the queue. Both members are ringing properly.
> * 'first-device' answers the call.
> * A second call arrives at the queue. Only the 'second-device' is ringing, as it is supposed to.
> * 'first-device' hangs up.
> * 'second-device' still ringing as it is supposed to but the 'first-device' doesn't receive the 'second-call' at all, despite the fact that there is wrapuptime = 0.
> * 20 seconds goes by and then the Queue retries both members which is normal.
> Based on wrapuptime definition, I think the call should immediately be placed on the first-device after hangup:
> ```
> ; After a successful call, how long to wait before sending a potentially
> ; free member another call (default is 0, or no delay)
> ;
> ;wrapuptime=15
> ```
> I tried different settings in queue configuration to see if there is a combination of variables that fix this behaviour, but with no luck.
> Tried with both Local and SIP queue members. I tested against a clean installation of asterisk 16.13.0 which is the current release for 16.
> All the tests are based on asterisk's sample files, I am attaching the SIP members scenario.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list