[asterisk-dev] app_queue: periodic-announce-frequency is not (always) respected for head-of-the-queue caller

[Matthew Jordan]

On Wed, Jun 25, 2014 at 12:54 PM, Stefano Lucetti
<stefano.lucetti at netresults.it> wrote:
> Hi all,
> I've stumbled upon an incorrect behavior of the app_queue "periodic-announce-frequency", which I would file as a bug, since I have not found a reference about this being an expected behavior or an already known bug. Sorry for the leghty mail, but I'd like to give all the details..
>
> Asterisk version is 1.8.15-cert1 (but I have not seen chagelogs regarding this aspect in following 1.8-cert versions)
>
> Basically, the periodic-announce-frequency is fully respected for callers who are not actively calling members but for head-of-the-queue callers the configured timer is not (always) respected.
>
> In the first case, the loop in the wait_our_turn() function checks every second if the time elapsed from previous announcement has reached the configured value.
>
> In the second case, the wait loop in the queue_exec() invokes (at least) two blocking functions, the try_calling() (which times out after "timeout" seconds) and the wait_a_bit() (which times out after "retry" seconds). Depending on these parameters value, the periodic-announce-frequency cannot be respected.
>
> A quite tedious description follows... The loop has 3 relevant phases:
>
> for (;;) {
>    ...
>    //TIMESTAMP A
>    say_periodic_announcement();
>    ...
>    //TIMESTAMP B
>    try_calling();
>    ...
>    //TIMESTAMP C
>    wait_a_bit();
>     ...
> }
>
> As an example, if periodic-announce-frequency is 20 seconds, timeout is 30 and retry is 5, we have that (let's have a single member in the queue) the timestamps before each function are (assume a 4 seconds long announcement):
>
> Loop 1:
> A 0 (announcement is not said)
> B 0
> C 30 (B+timeout)
>
> Loop 2:
> A 35 (announcement is played, since 35>20)
> B 39
> C 69
>
> Loop 3
> A 74 (announcement is played since 74 - 35 > 20)
>
> and so on.. So:
>
> - first announcement is played after first try_calling()+wait_a_bit() timeout: i.e. about 35 seconds after enqueue (instead of 20)
> - second announcement is played after 35 seconds from the end of previous one, and so on..
> There are actually more complicated cases based on the relationship among the three timers, but I think the issue is clear enough..
>
> I guess that to fix this, the say_periodic_announcement() should be invoked inside the wait_for_answer(), or in the ring_one() (checked at a fixed rate, just like for the wait_our_turn() function), but I don't know where and how..
>
> Is it something that could be fixed?
>

Generally, this is not a bug.

Announcements, by default, are not played to the first listener in the
queue. This is to prevent the situation where an agent picks up but -
because the person in the queue is getting an announcement - neither
party can talk to the other until the announcement is finished.

Because some people did feel that this was a bug, an option was added
mid-stream in 1.8.23.0, 'announce-to-first-user', that changes this
behaviour such that the first person in the queue does get
announcements. The aforementioned behaviour is a possibility, however
- so expectations should be set for your agents when this feature is
enabled.

Matt

-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org