[Home]

Summary:ASTERISK-25444: [patch]Music On Hold Warning misleading
Reporter:Conrad de Wet (Conrad)Labels:
Date Opened:2015-10-04 03:26:41Date Closed:2016-03-24 21:15:18
Priority:MajorRegression?Yes
Status:Closed/CompleteComponents:Resources/res_musiconhold
Versions:11.19.0 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:In a documented change from 11.18.0 to 11.19.0 - res_musiconhold.c line 894, change to warn about missing music on hold classes.

Both the version before and this one are not correct in any case - if you are using the RealTime engine for Music classes. Clearly this is not a popular way to handle MOH, because it has pretty much been like this since i can remember, but now with the change from debug to warning - its very confusing and annoying.

They are both incorrect, because the _get_mohbyname only checks if the class has been loaded to memory, and warns first before checking in the RealTime database. As a result, monitoring the CLI, we have no way of knowing if the correct music class has load or not. And our logs are getting clogged with incorrect warning messages.

Here you can see the output warns first, but then goes to the database and the correct classes loads...
{noformat}
[Oct  4 09:00:04] DEBUG[7779][C-00000002]: pbx.c:4938 pbx_extension_helper: Launching 'MusicOnHold'
   -- Executing [s@macro-et-music-on-hold:3] MusicOnHold("SIP/102-ConradInc-00000002", "") in new stack
[Oct  4 09:00:04] WARNING[7779][C-00000002]: res_musiconhold.c:896 _get_mohbyname: Music on Hold class 'default-ConradInc' not found in memory. Verify your configuration.
[Oct  4 09:00:04] DEBUG[7779][C-00000002]: res_config_odbc.c:114 custom_prepare: Skip: 0; SQL: SELECT * FROM MusicOnHold WHERE name = ?
[Oct  4 09:00:04] DEBUG[7779][C-00000002]: res_config_odbc.c:130 custom_prepare: Parameter 1 ('name') = 'default-ConradInc'
[Oct  4 09:00:04] DEBUG[7779][C-00000002]: res_odbc.c:1053 odbc_release_obj2: odbc_release_obj2(0x26f9be8) called (obj->txf = (nil))
[Oct  4 09:00:04] DEBUG[7779][C-00000002]: res_musiconhold.c:1098 moh_scan_files: Scanning '/var/lib/asterisk/moh/ConradInc/default' for files for class 'default-ConradInc'
   -- Started music on hold, class 'default-ConradInc', on SIP/102-ConradInc-00000002
[Oct  4 09:00:04] DEBUG[7779][C-00000002]: channel.c:3594 ast_settimeout_full: Scheduling timer at (50 requested / 50 actual) timer ticks per second
[Oct  4 09:00:04] DEBUG[7779][C-00000002]: channel.c:5413 set_format: Set channel SIP/102-ConradInc-00000002 to write format slin
[Oct  4 09:00:04] DEBUG[7779][C-00000002]: res_musiconhold.c:351 ast_moh_files_next: SIP/102-ConradInc-00000002 Opened file 3 '/var/lib/asterisk/moh/ConradInc/default/macroform-the_simplicity'
{noformat}

Furthermore, and just my 2c worth here, the real-time handling of music on hold is poor. Both "moh show classes", and "moh show files" is totally useless (when using musiconhold => odbc,MySqlRt,MusicOnHold)
Comments:By: Asterisk Team (asteriskteam) 2015-10-04 03:26:42.195-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: Rusty Newton (rnewton) 2015-10-06 17:34:17.041-0500

I don't think the WARNING is necessarily incorrect, however it does seem like we could be handling this more optimally from a user experience perspective.
By: Conrad de Wet (Conrad) 2015-10-07 02:07:18.243-0500

I have in the mean wile changed my src code back to a debug, and re-complied.

My reason for saying that the warning isn't correct is because it has not check if the moh class in in the real-time data. What would be a better solution:
1) Check if the moh class that is load in memory, if not, debug message "not found in memory" (as per 11.18).
2a) If using real-time - Check if moh class loaded from real-time, if not found in real-time data, warning message: "not found at all", going to try use default class" (or whatever message).
2b) If not using real-time - throw warning message (as per 11.19).

The main problem is in a high capacity environment - every single time someone enters a queue or puts someone on hold, or at any time refers to using music on hold, the warning message writes to the log... for us it was writing up to half a million times a day... in a real-life production environment, this is simply not feasible. (We re-write our logs to a db, so that we can perform a multitude of pattern match on them so we can identify potential problems, so changing the log level isn't an options either)