Summary:ASTERISK-18627: Music on Hold does not play mp3s until after res_musiconhold.so is reloaded manually.
Reporter:Robert Dailey (rdailey)Labels:
Date Opened:2011-09-26 09:50:17Date Closed:2011-10-05 08:43:30
Versions: Frequency of
Description:Music on Hold does not play mp3s until res_musiconhold.so is unloaded and loaded again.  On a fresh start-up, mp3s have no sound.  verbose output indicates that the moh class has started, and lsof shows that mpg123 is playing the mp3 files, but there is no sound from moh.  A class playing wav files plays normally.  The problem never fixes itself; I have to module unload then module load.  As soon as I have reloaded the module, calls using the mp3 class can hear the mp3 files or stream normally.  I tried preloading format_mp3.so, but it did not help.  I tried preloading all of the format_*.so files, and that didn't help either.  I have only tested and, but I have to assume the problem would exist if I had used earlier 1.8 versions as well.
Comments:By: Clod Patry (junky) 2011-09-27 21:42:30.824-0500

Do you mind copy your musiconhold.conf and the full CLI output?

It does this with any mp3?

By: Robert Dailey (rdailey) 2011-09-27 23:56:00.780-0500




 == Using SIP RTP CoS mark 5
   -- Executing [2000@phones:1] Goto("SIP/00096E12FFFF-00000000", "musiconhold,default") in new stack
   -- Goto (phones,musiconhold,2)
   -- Executing [musiconhold@phones:2] Answer("SIP/00096E12FFFF-00000000", "") in new stack
   -- Executing [musiconhold@phones:3] Set("SIP/00096E12FFFF-00000000", "CHANNEL(musicclass)=default") in new stack
   -- Executing [musiconhold@phones:4] Verbose("SIP/00096E12FFFF-00000000", "Starting default") in new stack
Starting default
   -- Executing [musiconhold@phones:5] MusicOnHold("SIP/00096E12FFFF-00000000", "") in new stack
   -- Started music on hold, class 'default', on channel 'SIP/00096E12FFFF-00000000'
   -- Stopped music on hold on SIP/00096E12FFFF-00000000
 == Spawn extension (phones, musiconhold, 5) exited non-zero on 'SIP/00096E12FFFF-00000000'

This problem occurs every time after a fresh start, until I unload and load the module.  Even moh reload is not sufficient.  Any mp3 files' sound never makes it to the phone.  Unload, then load... now mp3 files (and streams) will play to the phone.  If I unload/load, the CLI output is still the same.  I've tested it using SIP and also SCCP channel driver to eliminate any one channel tech as a possible cause.

By: Clod Patry (junky) 2011-09-28 07:21:17.713-0500

for your default MOH class, do you have the same behavior if you use mode=files instead of mode=mp3 ?

Since this could have something related to your modules loading, do you mind to attach your modules.conf as well?


By: Robert Dailey (rdailey) 2011-09-28 12:55:54.316-0500

If I set it to mode files, file.c and res_musiconhold.c cry that they cannot find the files (without file extension) in any format, and no such file or directory.  And they of course still never play.


noload => pbx_gtkconsole.so

noload => chan_alsa.so
noload => chan_oss.so
noload => chan_console.so

preload => pbx_config.so
preload => chan_local.so

noload => app_minivm.so
noload => app_festival.so

noload => cdr_odbc.so
noload => cdr_adaptive_odbc.so
noload => cdr_sqlite3_custom.so
noload => cdr_manager.so

noload => cel_pgsql.so
noload => cel_sqlite3_custom.so
noload => cel_odbc.so
noload => cel_manager.so
noload => cel_custom.so

noload => chan_mgcp.so
noload => chan_unistim.so
noload => chan_agent.so
noload => chan_skinny.so

noload => func_odbc.so

noload => pbx_ael.so

noload => res_config_odbc.so
noload => res_odbc.so
noload => res_stun_monitor.so
noload => res_pktccops.so
noload => res_config_ldap.so
noload => res_config_pgsql.so
noload => res_clialiases.so
noload => res_phoneprov.so
noload => res_smdi.so
noload => res_ael_share.so

By: Jonathan Rose (jrose) 2011-09-29 14:32:34.515-0500

Quick question... are you using music on hold by pressing hold during a phone call, or are you invoking it from the MusicOnHold application manually?  If you are using it from the dialplan, please post the relevant extensions.

On those lines, this is quite likely expected behavior if you are invoking musiconhold from the dialplan without first answering the line or starting early media with the Progress application.

On my box, all of this stuff just works.  Has it worked for you in any version of Asterisk or is this your first time using mp3s with Asterisk's MOH?

Other than that, I'd like to see your sip.conf and the relevant sip peer profile that you are using with music on hold.

By: Robert Dailey (rdailey) 2011-09-29 15:29:12.780-0500

It has always worked for me in all 1.4 versions I ever used.  I just recently made the switch to 1.8 and expected everything to work the same or nearly the same.  The fact that unloading the module and loading the module back gets it to work should indicate that it's a problem which isn't user error.  Reloading the module in this manner isn't going to correct a user error like you've described -- the problem would still exist after reloading the module.  You can see that the channel has been Answer()ed by looking at the verbose output listed in the comment above.

Current dial plan to test it:

exten => 2000,1,Goto(musiconhold,default);
exten => 2010,1,Goto(musiconhold,native);

exten => musiconhold,1,NoOp();
same => n(default),Answer();
same => n,Set(CHANNEL(musicclass)=default);
same => n,Verbose(Starting ${CHANNEL(musicclass)});
same => n,MusicOnHold();
same => n(native),Answer();
same => n,Set(CHANNEL(musicclass)=native);
same => n,Verbose(Starting ${CHANNEL(musicclass)});
same => n,MusicOnHold();

By: Clod Patry (junky) 2011-09-29 17:07:12.949-0500

im not sure to understand "If I set it to mode files, file.c and res_musiconhold.c cry that they cannot find the files (without file extension) in any format, and no such file or directory. And they of course still never play.".
You mean you have filename without extension?

whats ur output for: ls -lh /var/lib/asterisk/mohmp3/
and CLI's output for: moh show files

By: Robert Dailey (rdailey) 2011-09-29 18:39:12.854-0500

I mean file.c and res_musiconhold.c complained that instead of mymusic.mp3 it was trying to play mymusic which is not found in any format, and so did not work.  With all the things I have been doing testing this and other issues, I am no longer running the same build anymore, so I cannot reproduce THAT error; now when I use mode files it plays some mp3s, but usually gives a warning "mp3/interface.c:216 decodeMP3: Junk at the beginning of frame" before doing so.  It still won't play a stream unless I diddle moh though.  I'm going to stop messing with this problem for now and just work around it with an explicit unload/load.  I'll get back to this later.  I'm going to leave it open for the time being.

By: Jonathan Rose (jrose) 2011-10-05 08:42:50.341-0500

I don't really see any problem if you can't reproduce the bug any longer.  Junk at the beginning of the frame isn't important, and I think it might just be an issue related to extraneous data that mp3's store such as tags and things.  Not sure though.

If you can reproduce the original bug at a later date, please open a new issue.

By: Jonathan Rose (jrose) 2011-10-05 08:43:30.371-0500

Can not reproduce, closing.

By: Robert Dailey (rdailey) 2011-10-05 09:38:49.724-0500

The problem in the complaint is reproduced every single time I start or restart asterisk.  The problem did not magically go away.  As indicated, what I gave up on trying to reproduce was having file.c tell me that it couldn't find any files to play.  The bug still exists as far as I am concerned, because mp3 classes DO NOT PLAY SOUND on phones until after module unload res_musiconhold.so followed by module load res_musiconhold.so.