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

[Stefano Lucetti]

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? 

Thanks for the patioence..

Stefano