| Summary: | ASTERISK-27774: res_musiconhold: Music on hold restarts after every announcement | ||||||
| Reporter: | laszlovl (lvl) | Labels: | pjsip | ||||
| Date Opened: | 2018-03-26 07:30:18 | Date Closed: | 2018-04-17 12:13:33 | ||||
| Priority: | Major | Regression? | Yes | ||||
| Status: | Closed/Complete | Components: | Resources/res_musiconhold | ||||
| Versions: | 15.3.0 | Frequency of Occurrence | Constant | ||||
| Related Issues: |
| ||||||
| Environment: | Attachments: | ||||||
| Description: | The fix for ASTERISK-24329 is causing a regression during "regular" music on hold behavior.
Imagine a simple musiconhold setup, configured via realtime. {code} +--------+-------+------------------------+-------+ | name | mode | directory | sort | +--------+-------+------------------------+-------+ | 82497 | files | /ext/moh/82497 | alpha | {code} In /ext/moh/82497 are one or more audio files with a length of around 3 minutes. If a queue is configured with a periodic announcement every 30 seconds, the following will occur: * Caller hears music on hold file #1, playing from the beginning * After 30 seconds, the caller will hear the announcement * Caller hears music on hold file #1, playing from the beginning * After 30 seconds, the caller will hear the announcement * ... E.g., if the periodic announcement is made every 30 seconds the caller will only ever hear the first 30 seconds of music on hold over and over again. I don't fully understand the issue reported in ASTERISK-24329, but if this new behavior is indeed desirable in some cases I think it should be made configurable with the default behavior reverted back to how it was in 15.2. | ||||||
| Comments: | By: Asterisk Team (asteriskteam) 2018-03-26 07:30:19.100-0500 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. 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]. By: Joshua C. Colp (jcolp) 2018-03-26 09:42:36.357-0500 Have you only seen this under realtime music on hold or also with file based? By: laszlovl (lvl) 2018-03-26 09:59:38.497-0500 I just tested it on Asterisk 15.3.0, the behavior is the same with a musiconhold class defined in musiconhold.conf FYI, the verbose log: {code} -- Stopped music on hold on PJSIP/proxy-00000000 -- Playing periodic announcement -- <PJSIP/proxy-00000000> Playing '/var/prompts/announcement.slin16' (language 'nl') -- Started music on hold, class 'blah', on channel 'PJSIP/proxy-00000000' -- Stopped music on hold on PJSIP/proxy-00000000 -- Playing periodic announcement -- <PJSIP/proxy-00000000> Playing '/var/prompts/announcement.slin16' (language 'nl') -- Started music on hold, class 'blah', on channel 'PJSIP/proxy-00000000' -- Stopped music on hold on PJSIP/proxy-00000000 -- Playing periodic announcement -- <PJSIP/proxy-00000000> Playing '/var/prompts/announcement.slin16' (language 'nl') -- Started music on hold, class 'blah', on channel 'PJSIP/proxy-00000000' {code} The musiconhold starts from the beginning of the file after each "Started music on hold" log line. By: Friendly Automation (friendly-automation) 2018-04-17 12:13:34.324-0500 Change 8775 merged by Jenkins2: res_musiconhold: Don't restart MOH from beginning after announcement. [https://gerrit.asterisk.org/8775|https://gerrit.asterisk.org/8775] By: Friendly Automation (friendly-automation) 2018-04-17 12:19:34.781-0500 Change 8776 merged by Jenkins2: res_musiconhold: Don't restart MOH from beginning after announcement. [https://gerrit.asterisk.org/8776|https://gerrit.asterisk.org/8776] By: Friendly Automation (friendly-automation) 2018-04-17 12:23:23.066-0500 Change 8777 merged by Jenkins2: res_musiconhold: Don't restart MOH from beginning after announcement. [https://gerrit.asterisk.org/8777|https://gerrit.asterisk.org/8777] By: ben kolodny (benphone) 2022-01-24 11:31:43.606-0600 i seem to have the same problem with version 18.9.0 but it after playing the thank you message when Announce position: is set to yes the code that was fixed checks just announcement maybe position is treated differently any tips would be appreciated if (!state->announcement) { state->samples += f->samples [2022-01-24 18:50:36] VERBOSE[2643][C-00067771] app_queue.c: Nobody picked up in 20000 ms [2022-01-24 18:50:37] VERBOSE[2643][C-00067771] res_musiconhold.c: Stopped music on hold on PJSIP/fs2-00036104 [2022-01-24 18:50:37] VERBOSE[2643][C-00067771] file.c: <PJSIP/fs2-00036104> Playing 'pbx/188d949a5b9bbde4553ef85f252d8ddf.slin' (language 'he') [2022-01-24 18:50:40] VERBOSE[2643][C-00067771] app_queue.c: Told PJSIP/fs2-00036104 in 1507 their queue position (which was 1) [2022-01-24 18:50:40] VERBOSE[2643][C-00067771] file.c: <PJSIP/fs2-00036104> Playing 'queue-thankyou.gsm' (language 'he') [2022-01-24 18:50:42] VERBOSE[2643][C-00067771] res_musiconhold.c: Started music on hold, class '1435', on channel 'PJSIP/fs2-00036104' By: Kevin Harwell (kharwell) 2022-01-24 11:56:21.566-0600 [~benphone] This sounds like it might be a missed used case. Please create a new issue. On that new issue include a detailed description, and steps to reproduce. As well attach an Asterisk debug/verbose log file from an occurrence. Thanks! | ||||||