> There's no technical reason why app_conference couldn't go inside > asterisk. The code could be disclaimed, if people were interested in
> maintaining it in the core. > It _is_ maintained, as I use it all the time, but there's actually a > couple of issues which make it less than ideal at the moment: > 1) It wants all users to have 20ms frames, and will not be happy > otherwise (so, iLBC, etc are no good). There's a patch in Mantis that addresses the 20ms issue in Meetme. It's likely not ideal, but functional. > 2) it doesn't include _any_ features. > These can both be addressed, and it might be easier than trying to > change the meetme architecture. (also, (2) can be done more cleanly > than in meetme, because it can be external from the actual muxing > functionality). > I guess, you could also take the guts of app_conference, and > transplant them into meetme (you'd still need the disclaimer), but > then you'd still have all the muxing functionality mixed into the > features.. There's another patch in Mantis to start the task of making Meetme Realtime-enabled. The interest with this patch is it can be extended to support a scheduling and control process. I have been maintaining an out of tree module that checks scheduling and resource details and launchs app_meetme if all conditions are meet. I planned to merge these features into Meetme once Realtime support is in. In any case I would love to see either Meetme adopt some of app_conference's features or app_conference replace app_meetme. Dan _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
