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

[Tzafrir Cohen]

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.

Why is "reload" such a performance penalty? Maybe you need a lighter
"classes refresh" activity if it is?

> Each MoH could be in any place of filesystem,
> and you could specify order in which to play.
> 
> I just wanted to share my thoughts - i hope those who have already
> started - would do something this way..

-- 
               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