No MOH with parked call

Home » Asterisk Users » No MOH with parked call
Asterisk Users 6 Comments


Has anybody else noticed that MOH does not play on parked calls in Or is it just my setup? MOH seems to work in every other
respect (Call Held or in-Queue), but when a call is parked, the logs
show MOH being started, but the parked party hears nothing.

The verbose logs show the following. Any thoughts on whet to check next?


### Call comes in here and is answered

6 thoughts on - No MOH with parked call

  • href=””>

    Unloading worked to fix MOH for Parked calls, but
    it has killed call quality on ISDN calls – I think it interferes with
    the software echo canceller somehow.

    Is there a ticket open on this? A patch to try?


  • href=””>

    For anyone searching/finding this issue, the patch here:

    Applies to 1.6.2 with only a trivial tweak, and with minimal testing
    is working here. We now get music on hold when a call is parked, even
    when we are using – Call quality remains high
    under these circumstances too.

    Thanks for the pointers.


  • href=””>

    Hi Again,

    I thought I had this sorted, but it appears that in a clean
    environment I did not in fact fix it. There appears to be a bit of a

    1) In 1.6.2.x, musiconhold requires DAHDI (which we have)
    2) In 1.6.2.x parked calls get MOH only if res_timing_dahdi is not loaded…

    I am confused. MOH in general terms works just fine, but if I park a
    call with res_timing_dahdi loaded, I get silence after the orbit
    announcement. If I unload res_timing_dahdi, all works fine, but my
    timing sources are less reliable.

    I have backported res_musiconhold.c from 1.8 to, but this
    does not seem to fix things – is the problem elsewhere? Is there a fix
    that I can try, or perhaps backport?

    Thanks for any pointers.


  • Further to this, I have been slowly tracing through the codepath for a
    parked call – ast_settimer is called correctly for the MOH generator,
    and seems to set up the DAHDI timer exactly the same way as it does
    for the alternative timing modules, and all of the setup calls return
    success. I don’t have a verbose output trace to hand, but the sequence
    seems to be as follows: