[asterisk-bugs] [JIRA] (ASTERISK-29117) Zero wrapuptime is NOT respected in a ringall queue with local member and no ringinuse

[Ioannis Inglesis (JIRA)]

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

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

    Attachment: sip.conf
                queues.conf
                extensions.conf

Here is my sample confs for this problem

> Zero wrapuptime is NOT respected in a ringall queue with local member 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.2.1
>         Environment: Tested against Debian 9 - Stretch
>            Reporter: Ioannis Inglesis
>         Attachments: extensions.conf, queues.conf, sip.conf
>
>
> We a have a single queue that contains 2 Local 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. 
> I tried different settings in queue configuration to see if there is a combination of variables that fix this behaviour, but with no luck. 



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