Summary:ASTERISK-12506: Asterisk commands "moh reload" or "reload res_musiconhold.so" causes MOH not to work properly
Reporter:urzedo (urzedo)Labels:
Date Opened:2008-08-01 14:27:59Date Closed:2009-03-29 12:37:50
Versions:Frequency of
Description:SIP peer A is calling SIP peer B. When A put B on hold, B starts to listen to the MOH configured in the parameter "mohsuggest" of the peer A. If I look at Asterisk's verbose, I can see "Started music on hold..." and "Stopped music on hold..." stuff while peer A press the hold button.

During the above conversation, if someone runs "moh reload" or "reload res_musiconhold.so", than peer B is not able anymore to listen to the MOH when A press the hold button. In the Asterisk's verbose, I cannot see "Started music on hold..." and "Stopped music on hold..." anymore.

If "moh reload" or "reload res_musiconhold.so" commands are executed again, than everything starts to work again. And so on...
Comments:By: Dov Bigio (dovb) 2008-08-03 15:30:02

I also noticed this issue.
When I run "moh reload" or "reload res_musiconhold.so" the music that my callers listen to alternates between no sound and the right music.

If anybody needs help reproducing this, I can help.

By: urzedo (urzedo) 2008-08-07 14:20:54

Hi people,

Do we have any update on this question? This issue is really annoying...

Thanks in advance!

By: Leif Madsen (lmadsen) 2008-08-07 17:32:36

I'm not entirely convinced this is a bug since you're unloading/loading the module while it is in use. I'm not entirely sure how Asterisk would know what channels are then on hold when it is then reloaded without being told by the device.

By: Leif Madsen (lmadsen) 2008-08-07 18:00:24

Can you please clarify when the res_musiconhold.so is reloaded? Does it happen just in the middle of a conversation, or does it happen after you place someone on hold and the module is reloaded while the MoH is being played?

By: urzedo (urzedo) 2008-08-08 10:54:43

Hi blitzrage,

Let me clarify what actually happens:

- I start Asterisk process, all the config files are read and no errors are detected;

- All the calls placed have music on hold availble for both legs, according parameter "mohsuggest" set for each peer (I acctually use only SIP peers, so this parameter is set in sip.conf file);

- Then, at anytime, someone (via CLI) or something (for exemple, an external application via asterisk manager interface) issues a "moh reload" or "reload res_musiconhold.so". All calls placed AFTER the command is executed cannot hear to the music on hold anymore (the files are still there);

- Then, someone or something runs "moh reload" or "reload res_musiconhold.so" again. All calls placed AFTER this last event are able to listen to the MOH again. And so on.

After a little investigation, we found that there is a little patch included in version 1.4.11 to fix bug ASTERISK-9825, which introduced the piece of code below, in res_musiconhold.c:

   if (reload) {
     AST_LIST_TRAVERSE(&mohclasses, class, list)
              class->delete = 1;

If we remove this entire IF block from this same file in version, the issue I described above does not happen anymore.

Do you see any relation between the problem I found and the patch made to fix bug ASTERISK-9825?

Thanks in advance!

By: Leif Madsen (lmadsen) 2008-08-08 11:36:30

Thanks for the thorough update! I love seeing those kinds of notes.

I am going to assign this bug to russell since it appears he may have introduced the bug while fixing a bug I reported. We'll see what he thinks about the issue.


By: urzedo (urzedo) 2008-08-18 07:57:15

Hi blitzrage,

Is it possible to provide me with some update on this issue?


By: Leif Madsen (lmadsen) 2008-08-19 15:21:46

Unfortunately I have no update on the issue. Russell is extremely busy right now, and this issue is fairly low priority, so either he can re-assign to someone else who is willing to move this forward, or you'll just need to be patient for now.


By: Russell Bryant (russell) 2008-08-27 10:08:50

I can't seem to reproduce this using the latest Asterisk 1.4 code.  Can someone confirm that this is still a problem?

By: urzedo (urzedo) 2008-08-29 06:16:10

Hi russel,

We have just downloaded the latest code and we could simulate the issue again, exactly as discussed in my note #91240 (2008-08-08 10:54)


By: urzedo (urzedo) 2008-09-09 10:10:13

Hi Russel,

Were you able to simulate the issue?


By: Paulo Garcia (pgarcia) 2008-09-09 13:18:11


I'd like to add a piece of information here. I use streamplayer to provide music on hold with Asterisk If a channel is listening moh I can see a streamplayer process running normally.

When I issue a 'reload' or 'reload moh' command  (still playing the moh) I can see *two* streamplayer process running together. When I finish that call, the first process is killed and I have just one streamplayer process again but the moh using streamplayer won't work anymore which makes sense because the socket connection was ended and I didn't restart that connection to streamplayer.

So, to keep my software working, after a reload, I restarted socket connection to streamplayer. The next calls will listen to the moh normally but if there is a call listening during the reload, its moh will stop.

I don't know if it is the same issue reported here, but it seems that it is.


By: urzedo (urzedo) 2008-09-18 17:52:11

Hi guys,

I believe I could find a way to simulate this issue.

In a fresh Asterisk, create some MOH classes in musiconhold.conf and start Asterisk. If you issue a "moh show classes" command, you should see the classes in memory.

Now, make any change in musiconhold.conf file, such as adding a new class. Back to Asterisk CLI, issue "moh reload" command and after that "moh show classes". If you have added a new class, you will see that only this new class is in memory, while the other classes (which still exist in musiconhold.conf) have gone.

Issue "moh reload" command again and you will see that the former classes are back to memory, but the last created one is not there anymore. And so on...

Please let me know whether you can simulate it or not.


By: Leif Madsen (lmadsen) 2008-10-06 11:23:24

Hi urzedo,

I *was* able to reproduce with your 'moh show classes' method on Asterisk However, I was unable to reproduce this on Asterisk SVN 1.4 r146448, which seems to mean this issue is now resolved.

If this is not true, please feel free to find me on #asterisk-bugs on the Freenode IRC network as either blitzrage or lmadsen, and we can discuss and reopen if necessary.