[asterisk-dev] Issue with dahdi timing? MOH during parking issue.
davies147 at gmail.com
Thu Dec 30 12:03:22 UTC 2010
On 29 December 2010 17:11, Steve Davies <davies147 at gmail.com> wrote:
> 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 (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 and
> on chan->fds (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, 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 184.108.40.206-rc1 and dahdi 2.4.0 on Debian linux.
Thanks to Lee Archer pointing me in the right direction, I discovered
Which seems to fix this issue. Posting here in case someone else has
the same issue.
More information about the asterisk-dev