[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:01:36 CDT 2020


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

Ioannis Inglesis updated ASTERISK-29117:
----------------------------------------

    Affects Version/s:     (was: 16.2.1)
                       16.13.0

> 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
>
> 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 seconds 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