Summary:	ASTERISK-16585: Remove dahdi and meetme dependency for page function
Reporter:	rbosch (rbosch)	Labels:
Date Opened:	2010-08-17 19:29:22	Date Closed:	2015-02-26 09:28:13.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_page
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) app_page.hack
Description:	Most of the features now are independent of dahdi for a timing source now that there is kernel timing available in 1.6.2.  app_page.c is still dependent upon dahdi and meetme because uses meetme to merge the channels.  It would be better to remove that dependency.  I've attached a diff which changes the application to confbridge rather than meetme.  The recording feature isn't available but it seems like a better solution than the existing app_page.c since it removes the dependencies. Would it be possible to have the application detect if meetme is available at build time and then make the "r" option available if meetme is there?
Comments:	By: rbosch (rbosch) 2010-08-17 19:31:13 The simple replacement of confbridge works in my version of 1.6.2.11.  No dahdi or meetme is installed. By: rbosch (rbosch) 2010-08-18 10:04:38 I was looking at the app_page.c module a little more and it seems like the bridge dialplan option is a better approach than conferencing extensions together.  I'm going to do some more testing. By: Leif Madsen (lmadsen) 2010-08-24 12:43:20 This is already being worked on in ASTERISK-16441 :) By: Tilghman Lesher (tilghman) 2010-08-25 01:40:51 Actually, it isn't.  The use of a generic timer for musiconhold is unrelated to the use of MeetMe for mixing. By: Leif Madsen (lmadsen) 2010-08-25 10:38:13 If you're removing functionality from Page() (because ConfBridge() doesn't have recording, etc...) then I don't see the point here. Perhaps you should enable some sort of flag in the Page() application to control which application is used for mixing the channels? I would not support removing the ability to use Page() as it currently stands. By: rbosch (rbosch) 2010-08-25 12:39:45 That is a good idea.  The best option would be to check for the page application and if it is available go ahead and use that option.  If not, then write a warning  the log that confbridge is being used instead and recording isn't available.  Then use confbridge to mix the channels. I've been testing confbridge a little more and am having a few issues getting things to work.  I'll see what I can do but I don't have any license on file to submit a patch.   FYI, this is the same approach that patches I've supplied to freepbx do as well, check for an application that may require dahdi and if it is available use it (e.g. meetme) and if not, then use an alternative (confbridge) and reduce the options displayed to the end user.  This would be a similar tack taken in app_page.c. Does that make sense? By: Alex Hieronymi (stpaulalex) 2011-01-25 00:39:50.000-0600 Update: This does not resolve the issue outlined in 0017896 (MulticastRTP in Page() yield garbled audio).  The audio is still garbled when using more than one channel with multicast in the page() application, even with the change to ConfBridge. By: Matt Jordan (mjordan) 2015-02-26 09:28:13.094-0600 The {{Page}} application was migrated to use {{ConfBridge}} under the hood in Asterisk 11.