asterisk users - Sep 2011 - bounty for ASTERISK-17474 streaming MusicOnHold bug

Hi all-

This is my first post to this list so please don't flog me if this is not
the appropriate place to post this.  I've had an issue for over a year
affecting MOH + DAHDI timers, I reported it at:

https://issues.asterisk.org/jira/browse/ASTERISK-17474

 

Basically the MOH channel goes dead after a 'moh reload' command is
issued
(these are streaming sources that use mpg123) and will not start back up
unless you do a full asterisk stop/start.  The issue hasn't caught
anyone's
attention yet.  So I thought I'd try to put together a bounty to spark some
interest in fixing this issue.  Is anyone else interested in putting up
something to get this bug fixed?  I'd be willing to put up $100 myself.  If
there's any support I would create the bounty on
http://www.voip-info.org/wiki/view/Asterisk+bounty  -- is that the correct
way to do it? 

 

thanks,

Luke

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20110922/4cc1bb25/attachment.htm>

From: asterisk-users-bounces at lists.digium.com
[mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of Luke Hamburg
Sent: Thursday, September 22, 2011 3:24 PM
To: asterisk-users at lists.digium.com
Subject: [asterisk-users] bounty for ASTERISK-17474 streaming MusicOnHold
bug

 

Hi all-

This is my first post to this list so please don't flog me if this is not
the appropriate place to post this.  I've had an issue for over a year
affecting MOH + DAHDI timers, I reported it at:

https://issues.asterisk.org/jira/browse/ASTERISK-17474

 

Basically the MOH channel goes dead after a 'moh reload' command is
issued
(these are streaming sources that use mpg123) and will not start back up
unless you do a full asterisk stop/start.  The issue hasn't caught
anyone's
attention yet.  So I thought I'd try to put together a bounty to spark some
interest in fixing this issue.  Is anyone else interested in putting up
something to get this bug fixed?  I'd be willing to put up $100 myself.  If
there's any support I would create the bounty on
http://www.voip-info.org/wiki/view/Asterisk+bounty  -- is that the correct
way to do it? 

 

thanks,

Luke

 

My .02

1.       This is a 1.8.X issue, so anything I say is purely conjecture,
since I am a 1.4 hardliner

2.       Don't know if moving to 10.x would help you, but since that is
still considered beta, that's probably not an option anyhow.

3.       My understanding is that bounties need to be posted on the
asterisk-dev list.

4.       With those caveats, have you tried this: 

Copy the load_module and unload_module routines from res_timing_pthread.c to
res_timing_dahdi.c (you'll probably need some includes to make it compile
right).  IMO the "final answer" for you will be a "hybrid"
res_timing module
that combines these two.

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20110922/94f0431d/attachment.htm>

Danny Nicholas wrote:
>> 2. Don't know if moving to 10.x would help you, but since that is
still
considered beta, that's probably not an option anyhow.

Yup, not really an option for me.  I actually use this system daily and
don't want to muck around with 10.0 just yet.
>> 3. My understanding is that bounties need to be posted on the
asterisk-dev list.

Fair enough, I couldn't find that info - can anyone else confirm this?  I
don't want to go barging into the dev list looking like a fool.
>> 4. With those caveats, have you tried this: Copy the load_module and
unload_module routines from res_timing_pthread.c to res_timing_dahdi.c
(you'll probably need some includes [..]

Hehe - no I definitely haven't tried that.  That's a bit above my pay
grade
for now.  I was hoping to find a more formal fix for this.  Still clinging
onto the idea that with a decent bounty put together, someone who knows the
code well enough would be able to fix this.  The fact that it WORKS GREAT
until the first 'moh reload' suggests to me that it might be a
relatively
easy bug to squash.

Right -- I've been wrestling with this problem for over a year now.
Tinkering with modules.conf load order, "noload= / preload=" etc I
even
modified the internal "priority" of the timers in the C code of the
timing
modules so that after a reload the pthread timer would still be at a higher
prio than the DAHDI timer. For example in res_timing_pthread.c: around line
54: "priority = 0" change to "priority = 250" which puts it
higher than
DAHDI.  That hack actually worked but messed up so many other things that it
was useless in production.  

The only "real" solution is going to be someone diving into the
res_musiconhold.c code to figure out
a) why after reload does it use the dahdi timer instead of pthread
b) why doesn't it play nice with the dahdi timer

It could be a bug in res_timing_dahdi or res_musiconhold, or even somewhere
else.  I wish I knew more about the code to debug this.  That's why I
thought maybe starting the bounty would help.  Vladimir I know you're
affected by this bug too as I've seen you posting to the bugtracker -- would
you be interested in putting up any $ towards the bounty?  I think if I
could get $500 together someone might take it upon themselves to actually
fix this once and for all...


-----Original Message-----
From: Danny Nicholas [mailto:danny at debsinc.com] 
Sent: Monday, September 26, 2011 10:43 AM
To: 'Asterisk Users Mailing List - Non-Commercial Discussion'
Subject: Re: [asterisk-users] bounty for ASTERISK-17474 streamingMusicOnHold
bug

Too early in the day - as I read this "dahdi restart" probably
won't work
correctly in the scenario as I follow it.  The only workable scenario I see
here is an asterisk restart since the dahdi timers "hose the works";.