Summary:	ASTERISK-30437: app_queue ability to start periodic announcements at a different time than the playing interval (frequency)
Reporter:	Jaco Kroon (jkroon)	Labels:
Date Opened:	2023-02-24 03:24:22.000-0600	Date Closed:	2023-03-16 09:25:44
Priority:	Trivial	Regression?
Status:	Closed/Complete	Components:	Applications/app_queue
Versions:	16.30.0 18.16.0 19.8.0 20.1.0	Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	We have a client that wants a periodic announcement to play immediately upon entering the queue and then at the requested interval. After code inspection it seems that whilst playing the announcement it doesn't ring through to agents regardless and vice versa (which means we could just do Playback(), but that would also play the announcement even when the call is immediately without waiting queued to an agent). Upon raising this internally we realized that this would also benefit other customers, after engaging with a few of them the request was to be able to play an announcement a few seconds into a call (typically 10 to 45 has been the feedback) and then repeat at anything from 30 to 120s intervals. Since the repeating mechanism is already in place, we've implemented code to just control the start time for the first announcement by manipulating the last_periodic_announce_time upon entering the queue, setting it to a value in the past (or the future if startdelay > frequency) such that the periodic announcement will only commence playing at startdelay seconds into the call.
Comments:	By: Asterisk Team (asteriskteam) 2023-02-24 03:24:25.801-0600 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. Please note that log messages and other files should not be sent to the Sangoma Asterisk Team unless explicitly asked for. All files should be placed on this issue in a sanitized fashion as needed. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur. Please note that by submitting data, code, or documentation to Sangoma through JIRA, you accept the Terms of Use present at [https://www.asterisk.org/terms-of-use/|https://www.asterisk.org/terms-of-use/]. By: Friendly Automation (friendly-automation) 2023-03-16 09:25:46.019-0500 Change 19951 merged by Friendly Automation: app_queue: periodic announcement configurable start time. [https://gerrit.asterisk.org/c/asterisk/+/19951|https://gerrit.asterisk.org/c/asterisk/+/19951] By: Friendly Automation (friendly-automation) 2023-03-16 10:43:40.472-0500 Change 19899 merged by Joshua Colp: app_queue: periodic announcement configurable start time. [https://gerrit.asterisk.org/c/asterisk/+/19899|https://gerrit.asterisk.org/c/asterisk/+/19899] By: Friendly Automation (friendly-automation) 2023-03-16 10:44:01.060-0500 Change 19950 merged by Joshua Colp: app_queue: periodic announcement configurable start time. [https://gerrit.asterisk.org/c/asterisk/+/19950|https://gerrit.asterisk.org/c/asterisk/+/19950] By: Jonathan Rose (JonathanRRose) 2023-04-11 14:21:27.309-0500 This patch has a problem that was revealed to me by clang-tidy. https://github.com/asterisk/asterisk/blob/edd7f1b0605e2840b2e21bf45afa67950dd3f9fe/apps/app_queue.c#L8529 At this line, qe.parent is assumed non-null and it's actually impossible for it to be anything *other* than null at this point. This results in a null pointer dereference and I'm pretty sure that's going to cause a crash (and if it doesn't, it won't work as intended anyway). There's actually an assert for qe.parent being not null a little further down the line, but that's only after qe has been consumed by join_queue. This is where qe.parent actually gets set. By: Joshua C. Colp (jcolp) 2023-04-11 14:34:18.013-0500 [~JonathanRRose] A new issue should be created for that so it can be marked as a blocker for the next releases. [~jkroon] Will you be looking at this? By: Jonathan Rose (JonathanRRose) 2023-04-11 17:59:29.329-0500 @jcolp I went ahead and confirmed my suspicions with a basic test and all uses of Queue() now crash w/ segfault. Ticket is over here: https://issues.asterisk.org/jira/browse/ASTERISK-30492