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

[Atis Lezdins]

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 "reload" such a performance penalty? Maybe you need a lighter
> "classes refresh" activity if it is?

Well, i don't say that it's performance penalty - if you use it wisely -
it can gain quite some performance. However in my opinion "reloads" is
not the best way for dynamic call-center. There are lot of people who
just wants to add file (SIP settings or whatever else), so that it would
just work - and realtime brings it to them.

Realtime can mean more performance loss, but users do have a choice, right?

Regards,
Atis