[asterisk-dev] Bounty for real-time musiconhold.conf

[Tzafrir Cohen]

On Wed, Nov 07, 2007 at 01:18:27PM +0200, Atis Lezdins wrote:
> Tzafrir Cohen wrote:
> > On Wed, Nov 07, 2007 at 12:05:40PM +0200, Atis Lezdins wrote:
> >> Tzafrir Cohen wrote:
> >>> On Tue, Nov 06, 2007 at 10:03:37PM -0500, Leif Madsen wrote:
> >>>> Igor A. Goncharovsky wrote:
> >>>>> Hi!
> >>>>> Alistair Cunningham writes:
> >>>>>> I've now posted a bounty page at:
> >>>>>>
> >>>>>> http://www.voip-info.org/wiki/view/Asterisk+bounty+realtime+musiconhold.conf
> >>>>>>   
> >>>>> I do not understand what reason to make musiconhold realtime? To change
> >>>>> in realtime sort order or directory with files?
> >>>>>   
> >>>> I've run into this issue when building hosted PBXs. Without realtime 
> >>>> musiconhold, then when you add a new entry to the musiconhold.conf file, 
> >>>> you have to reload the res_musiconhold.so module. By having it in 
> >>>> dynamic realtime (I do it in static realtime when clustering, but you 
> >>>> still have to reload the musiconhold.so module), then when you add an 
> >>>> entry to the database from a GUI, or other external script, then 
> >>>> Asterisk could load it from the DB automatically the next time MoH is 
> >>>> called.
> >>> And why not expose the functionality of "moh reload" through a proxy
> >>> manager interface script?
> >>>
> >> It's already exposed trough manager - you can use any CLI command.
> > 
> > Sure. The proxy can simply be the web interface itself.
> > 
> >> Hearing of realtime MoH sounds nice (i'm personnaly not fan of "reload"
> >> style). If there's a lot of users, and each is doing some changes often,
> >> you can get the state, when asterisk is just working on reloading
> >> everything again and again..
> >>
> >> My idea of realtime MoH wouold be - whenever called, it would do SQL
> >> request - i.e. SELECT * FROM moh WHERE class='default' AND prio=1
> >> hen it would play it, and do next select - SELECT * FROM moh WHERE
> >> class='default' AND prio=2
> > 
> > Or alternatively, use a "custom" player and get everything back to an
> > external player command.
> > 
> > If you have many people playing the same music, a custom player may save
> > much performance. OTOH, if you have many different moh classes, it would
> > require maintaining many different player proceeses, and thus may not be
> > a good idea.
> > 
> >> That way - anything could be changed on-the-fly, without complex data
> >> structures and relads.. 
> > 
> > The "complex data structure" is the directory tree. One possible option
> > is to just build a symlinks directory to each user, or some variation on
> > that. Thus you can use renaming of files and such to reorder songs just
> > in one class. THen you only need a reload when you add / remove a user
> > (assuming a moh class per user). 
> > 
> > When using realtime, the penalty is even larger: on each time you start 
> > to play a song. Regardless of reload activity.
> 
> Well, i've seen that moh caches files.. i noticed yesterday that i also
> need "moh reload" after adding or removing file. I haven't looked into
> sources, but seems that contents of dir get cached as well..

Why is this caching needed? Perhaps a better "realtime" option would be
a directory rescanning on each new play?

And maybe make it a per-class decision?

-- 
               Tzafrir Cohen       
icq#16849755              jabber:tzafrir.cohen at xorcom.com
+972-50-7952406           mailto:tzafrir.cohen at xorcom.com       
http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir