On 7 December 2010 17:47, Steve Davies <[email protected]> wrote: > On 7 December 2010 15:00, Steve Davies <[email protected]> wrote: >> On 7 December 2010 14:17, Lee Archer <[email protected]> wrote: >>> Hi, try unloading res_timing_dahdi.so then trying again. >>> >>> Lee >>> >>> -----Original Message----- >>> From: [email protected] >>> [mailto:[email protected]] On Behalf Of Steve >>> Davies >>> Sent: 07 December 2010 12:54 >>> To: Asterisk Users Mailing List - Non-Commercial Discussion >>> Subject: [asterisk-users] No MOH with parked call >>> >>> Hi, >>> >>> Has anybody else noticed that MOH does not play on parked calls in >>> 1.6.2.14? 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? >>> >>> Thanks, >>> Steve >>> >>> >>> ### Call comes in here and is answered >>> -- SIP/snom360-00000d6f answered DAHDI/2-1 >>> -- Executing [...@macro-set-moh-call:1] GotoIf("SIP/snom360-00000d6f", >>> "0?done") in new stack >>> -- Executing [...@macro-set-moh-call:2] Set("SIP/snom360-00000d6f", >>> "CHANNEL(musicclass)=m-default") in new stack >>> -- Executing [...@macro-set-moh-call:3] NoOp("SIP/snom360-00000d6f", >>> "") in new stack >>> >>> ### Here the call is being blind transferred to the Park number >>> -- Started music on hold, class 'default', on DAHDI/2-1 >>> -- Stopped music on hold on DAHDI/2-1 >>> == Spawn extension (local, 210, 1) exited non-zero on 'DAHDI/2-1' >>> -- Executing [...@local:1] ForkCDR("DAHDI/2-1", "") in new stack >>> -- Executing [...@local:2] Set("DAHDI/2-1", "CDR(userfield)=") in >>> new stack >>> >>> ### Not sure why I send "Ringing" here, but I tried NoOP() and >>> Answer() too just in case >>> -- Executing [...@local:3] Ringing("DAHDI/2-1", "") in new stack >>> -- Executing [...@local:4] Set("DAHDI/2-1", >>> "CHANNEL(musicclass)=default") in new stack >>> -- Executing [...@local:5] Set("DAHDI/2-1", >>> "CHANNEL(parkinglot)=default") in new stack >>> -- Executing [...@local:6] Goto("DAHDI/2-1", >>> "parkedcalls_default,park,1") in new stack >>> -- Goto (parkedcalls_default,park,1) >>> -- Executing [p...@parkedcalls_default:1] Park("DAHDI/2-1", "") in >>> new stack >>> == Parked DAHDI/2-1 on 211 (lot default). Will timeout back to >>> extension [parkedcalls_default] s, 1 in 90 seconds >>> -- Added extension '211' priority 1 to parkedcalls_default >>> (0xbe2e528) >>> >>> # The "211" announcement is heard perfectly >>> -- <DAHDI/2-1> Playing 'digits/2.alaw' (language 'en') >>> == Extension Changed 211[extensions] new state InUse for Notify User >>> steve >>> -- <DAHDI/2-1> Playing 'digits/1.alaw' (language 'en') >>> -- <DAHDI/2-1> Playing 'digits/1.alaw' (language 'en') >>> >>> # The system claims to start MOH "default" which works elsewhere, but >>> the caller gets silence >>> -- Started music on hold, class 'default', on DAHDI/2-1 >>> == Spawn extension (parkedcalls_default, s, 1) exited non-zero on >>> 'Parked/DAHDI/2-1<ZOMBIE>' >>> >> >> Unloading res_timing_dahdi.so 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? >> >> Thanks, >> Steve > > For anyone searching/finding this issue, the patch here: > > https://issues.asterisk.org/view.php?id=17726 > > 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 res_timing_dahdi.so - Call quality remains high > under these circumstances too. >
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 contradiction. 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 1.6.2.16-rc1, 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. Regards, Steve -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
