Summary:	ASTERISK-03586: [patch] Pluggable PBX's
Reporter:	Anthony Minessale (anthm)	Labels:
Date Opened:	2005-02-25 11:40:54.000-0600	Date Closed:	2005-04-01 22:42:49.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) ppbx_rev0.diff ( 1) res_pbx_demo.c
Description:	I mentioned this in the meeting so I thought i'd give a working example. This lets you register your own entire pbx to replace the standard one.  Think of it as a "super app" that is called on the channel the minute it's born and it never enters the builtin dialplan.  This app has the responsibility to destroy the channel before exiting. This is just to see if it'd work included is a very simplistic proof of concept pluggable_pbx and modifications to chan_iax.c to allow you to add ppbx=MyPBX to the peer section which causes all calls on the peer to hit the demo. Maybe it's stupid I thought i'd flesh it out to find out for sure if it's of any use. ****** ADDITIONAL INFORMATION ****** Disclaimer on file anthmct@yahoo.com
Comments:	By: Mark Spencer (markster) 2005-02-25 11:50:56.000-0600 I imagine you had intended to attach a patch... By: Anthony Minessale (anthm) 2005-02-25 12:05:00.000-0600 DoH! By: Mark Spencer (markster) 2005-02-25 12:41:06.000-0600 Why not just change the starting extension? By: Anthony Minessale (anthm) 2005-02-25 12:56:33.000-0600 The Idea was to bypass pbx.c and own the top level of the chan's thread so you can implement your own pbx, extension logic, etc. The example discussed during the phone call was to let the various scripting languages like res_perl implement thier own entire implementation of the pbx or start a new generation of apps that only live in some new nifty pbx in theory you could make the rest of pbx.c into such a lodable module called res_pbx_default.so </Brain Storming> By: Clod Patry (junky) 2005-03-08 23:05:24.000-0600 Not sure to get the real point here. It's to gain any speed without having the need to enters the builtin dialplan? More details would be appreciated. I've missed that meeting, someone recorded it? Any link? Thanks. By: Tilghman Lesher (tilghman) 2005-03-09 00:29:35.000-0600 No, the idea is to make almost every piece of code into a module.  I'm not sure I agree with the premise, but this is an illustration of taking modularity to one far extreme. As Mark has already vetoed making the manager a module, I don't see how this has any chance of making it into CVS. By: Anthony Minessale (anthm) 2005-03-09 09:14:10.000-0600 If anyone cares I can elaborate.  Keep in mind I have no loyality to this patch as its a proof of concept and the reasoning was as follows: The existing pbx has some serious issues that come into play when you scale it past a small to medium dialplan and the logic behind the interaction of apps and extension also have some obvious issues that are not in the scope of this explanation.  During the dev call we discussed these issues and concluded it would be nice to be able to make a new way to handle dialplan and apps but the cost would be very high if it broke asterisk for weeks so the logic behind the pluggable pbx was to allow you to construct an entire new way to handle the lifespan of a call without breaking the existing functionality.  So basicly you could begin asterisk 2.0 from within 1.x.  As far as manager,  Yes mark has vetoed making manager a module which I would only agree with if he intends to erase it completely and insert a nicer event system so existing modules could interact with it easier this point has also been duely noted on mutiple occasions during the weekly call. By: Terry Wilson (twilson) 2005-03-24 23:07:41.000-0600 I don't carry much weight around here, but it sounds like an intriguing idea to me.  Even just as a development tool it seems it would be handy for bridging between any versions that may or may not be completely compatible. This would definitely make it easier for third-party customization i.e. tailoring a realtime dialplan based on an existing customer database structure for example (i.e. making it easy to write a pbx module so that someone could replace another proprietary product without having to really migrate a lot of their data--dialing permissions, least-cost routing, etc.). Anyway, just my $0.02. By: Mark Spencer (markster) 2005-03-26 01:49:31.000-0600 I think I still need to understand how this differs from just having something like: [context] exten => _.,1,MyCustomDialplan() or even: [context] switch => MyCustomPBX Either one could give full control with essentially no overhead. By: Terry Wilson (twilson) 2005-03-26 02:32:27.000-0600 For one, I absolutely detest switches.  Maybe I just don't use them properly, but let me propose a situation: you have an web interface that allows you to add users at will who can make changes to their dialplan in real time.  Some users will have overlapping extensions so they of course need to be in different contexts.  You have a "huge" dialplan and don't want to have to do reloads--especially since you have a large number of customers all changing their dialplan at once and you don't want to use a cron job to do a reload every n minutes (because one of the things they are changing is things like forward on no answer which users usually are doing right as they are walking out the door and don't want to wait for it to take effect). Now, lets say you decide to use realtime extensions which are based on the switch statement.  From what I can tell, there is no way to say "Lookup all of my extensions in every context via realtime."  You need to first have the context exist in a non-realtime with a switch statement in it.  So you still have to do reloads which is the whole reason you wanted to use realtime.  (Sorry, this kind of devolved into a rant on realtime extensions... if I am missing something on how to do this with the realtime switch, let me know) My current solution is to do something like your first option with res_perl because it seems to be the only way for me accomplish the above, but it just feels like a hack using an App for our whole dialplan.  This would give people the option of specifying their dialplan in an Asterisk-friendly way in any format that they choose. Another example: Mark, you hate XML.  Some people (although I am not yet one of them) like it and have invested a lot of energy in it.  There is even an RFC out there for CPL-an XML based call processing language.  If someone so chose, they could implement this as a Pluggable PBX and use the dialplan that some other product that uses CPL generates for its dialplan with asterisk  without having to make any changes to their existing front-end for creating a dialplan. I guess the rule about people always finding uses for something you write that you hadn't thought of applies in this case.  Giving the option for a pluggable PBX gives people a lot of ability to change how they use Asterisk. By: Kevin P. Fleming (kpfleming) 2005-03-31 15:08:35.000-0600 That was the whole idea behind this patch, yes. While there is not really any way to build a complete alternative PBX core today easily (since you'd have to link it to most of the Asterisk API to actually do the call control), it can be done. People like having options :-) By: Mark Spencer (markster) 2005-04-01 19:56:52.000-0600 If you want to have just one alternative PBX module, it could be implemented fairly easily.  If you want it to be selectable on a per-user/peer basis, then I recommend just using a custom switch and then mapping the contexts (which are already selectable per user / peer) to the given switch.