[asterisk-users] No MOH with parked call

[Steve Davies]

On 7 December 2010 17:47, Steve Davies <davies147 at gmail.com> wrote:
> On 7 December 2010 15:00, Steve Davies <davies147 at gmail.com> wrote:
>> On 7 December 2010 14:17, Lee Archer <Lee.Archer at thebigword.com> wrote:
>>> Hi, try unloading res_timing_dahdi.so then trying again.
>>>
>>> Lee
>>>
>>> -----Original Message-----
>>> From: asterisk-users-bounces at lists.digium.com
>>> [mailto:asterisk-users-bounces at lists.digium.com] 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 [s at macro-set-moh-call:1] GotoIf("SIP/snom360-00000d6f",
>>> "0?done") in new stack
>>>    -- Executing [s at macro-set-moh-call:2] Set("SIP/snom360-00000d6f",
>>> "CHANNEL(musicclass)=m-default") in new stack
>>>    -- Executing [s at 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 [210 at local:1] ForkCDR("DAHDI/2-1", "") in new stack
>>>    -- Executing [210 at 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 [210 at local:3] Ringing("DAHDI/2-1", "") in new stack
>>>    -- Executing [210 at local:4] Set("DAHDI/2-1",
>>> "CHANNEL(musicclass)=default") in new stack
>>>    -- Executing [210 at local:5] Set("DAHDI/2-1",
>>> "CHANNEL(parkinglot)=default") in new stack
>>>    -- Executing [210 at local:6] Goto("DAHDI/2-1",
>>> "parkedcalls_default,park,1") in new stack
>>>    -- Goto (parkedcalls_default,park,1)
>>>    -- Executing [park at 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