On Wed, Jun 25, 2014 at 12:54 PM, Stefano Lucetti <[email protected]> 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 -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
