Summary:	ASTERISK-21270: Bridge API Enhancements - add subclassing ability to ast_bridge
Reporter:	Matt Jordan (mjordan)	Labels:
Date Opened:	2013-03-15 09:13:14	Date Closed:	2013-03-25 17:50:19
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Core/Bridging
Versions:	12	Frequency of Occurrence
Related Issues:	must be merged before resolving ASTERISK-21271 Bridge API Enhancements - subclass ConfBridge with its own Virtual Method table must be merged before resolving ASTERISK-21272 Bridge API Enhancements - subclass Parking with its own Virtual Method table
Environment:		Attachments:
Description:	Currently, bridge mixing technologies have the ability to be subclassed. However, the bridges themselves cannot - thus, while ConfBridge uses the softmix bridge mixing technology, it cannot override behavior that occurs when a channel joins, leaves, etc. Ideally, applications would be able to provide their own concrete implementations of {{ast_bridge}} such that they can override (if they choose) the behavior of a channel joining, departing, imparting, etc. They would still need to call the base class implementations (as {{ast_bridge}} will always be doing critical things with the channel), but they should be able to provide their own behavior when needed. Note that this is similar to the API extension points, except that it's a bit more permissive in what is made available to applications. The intent here is that something like ConfBridge would be able to provide it's own bridge; a completely separate external application would be able to register observers that would be notified when something changes in ConfBridge's bridge (but would not necessarily change how that action took place). At the end of this task, we should have: * A virtual method table that let's applications implement their own callbacks for common operations * A private data pointer for bridges separate from the mixing technology data pointer
Comments: