[asterisk-dev] Issue with dahdi timing? MOH during parking issue.

[Steve Davies]

On 29 December 2010 17:11, Steve Davies <davies147 at gmail.com> wrote:
> Hi,
>
> I asked about this on asterisk-users, and got a couple of suggestions,
> but it has now gone silent. I've been digging a bit, but have hit a
> wall, and was hoping for a pointer as to where to look next?
>
> MOH works fine 99% of the time. In fact the only time it does not work
> is for a parked call when res_timing_dahdi.so is loaded. I do not
> believe that the issue lies in res_musiconhold.so as this appears to
> use a timer for mp3 music sources, but an external generator/timer is
> used if MOH is using raw files (as I am).
>
> I have scattered debug all over the res_timers*.c,  features.c and
> channel.c, and see the following occur during a working and non
> working call park:
>
> - Timer1 opened and started (I assume by chan_sip in this case)
> - Timer1 generator fires regularly (creating silence?)
> - Call proceeds and is parked
> - Timer2 opened and started (for the parking thread I assume)
> - Timer2 becomes the chan->timer value to replace Timer1
> - Park position is played, and timer2 is stopped/started to do this.
> - Timer2 is started for use with MOH
> - Timer1 is closed here
>
> At this point, Timer2 should be running, and is correctly referenced
> in chan->timer and in chan->fds[8] (AST_TIMING_FD is 8), the sequence
> is identical so far whether res_timing_dahdi.so or
> res_timing_pthread.so is loaded.
>
> At this point things differ:
>  res_timing_pthread.so - poll events occur both on chan->fds[0] and
> on chan->fds[8] (the timing FD) and MOH works fine.
>  res_timing_dahdi.so - poll events on the timing FD seem to stop, but
> continue on chan->fds[0], MOH does not work.
>
> Because the timing FD is not firing, the generator is not called, and
> no MOH data is read from the files, resulting in silence.
>
> I have confirmed that the timer's FD is still listed in pfds[], but is
> never returning POLLIN once Timer1 is closed. My concern is that this
> is a dahdi pseudofd bug, and I am certainly not qualified to go
> messing with kernel modules :(
>
> Any thoughts where to look next? Can anyone else even replicate this?
> I am using asterisk 1.6.2.16-rc1 and dahdi 2.4.0 on Debian linux.

Thanks to Lee Archer pointing me in the right direction, I discovered

    https://issues.asterisk.org/view.php?id=18262

Which seems to fix this issue. Posting here in case someone else has
the same issue.

Many thanks,
Steve