Hello folks, As has been recently discussed I've been working on a new bridging API. What will this give us? Better control over bridges, more features, and a general cleaner API. Now on to the good stuff...
NOTE: Some of the stuff described here is not yet written, simply on my white board. I'm knocking out the big pieces first and then going after the rest. 1. Bridging technologies A bridging technology in the eyes of this bridging API is a module that is responsible for mixing or exchanging frames. Currently there are two working modules, bridge_simple and bridge_zaptel. bridge_simple simply takes in frames and passes them through to the other channel. bridge_zaptel takes audio frames, puts them into a pseudo zaptel channel, and discards the others. Bridge technologies also have capabilities, preferences, and formats attached to them. Capabilities indicate whether it is capable of mixing multiple sources, whether it can do native bridging, etc. When a bridge is built the developer requests capabilities and the bridging core finds the "best" way to accommodate them. The preferences information is used to determine which bridge technology to use when multiple ones are available. In the case of multiple source mixing if bridge_zaptel was loaded with bridge_softmix (userspace software mixing) then bridge_zaptel would get preference. Formats are used to put the channel that is going to be in the bridge into the correct read/write format. The bridge technology does not have to worry about it. This is not to say a bridge technology can not replace this functionality. bridge_simple itself does this by supporting every format and doing it's own stuff in it's module. 2. Bridging core The core can operate in a few different ways depending on how the bridging technology was developed. There can be a central thread handling all channels, each channel can be handled by it's own thread, or a combination of the two. No matter which way is used though they all act the same from the perspective of a developer using the API. This is rather... general but if anyone has any specific questions feel free to ask and I will be happy to answer. 3. Bridging feature flags These allow a developer to tweak the behavior of the bridge. In the case of a simple two party bridge you would want the bridge to terminate about hangup of one of the channels. This is one of the current feature flags available. There is also a feature flag to make the bridge a bit smarter and automatically transition between bridging technologies as channels are added. A two channel bridge would start off using bridge_simple most likely and transition to bridge_zaptel once another was added. 4. DTMF Features This is what I have been designing the last few days. There will be built in features as there is today for blind transfers, attended transfers, etc. Configured DTMF feature sets will also be available as they are today using their own API call. And finally... there will also be the capability (as a developer) to register custom DTMF feature sets per bridge. In the case of a conference bridge this can be used for the IVR portion. Hit a key (or series of keys) and control of the channel is given to your application. All of these will be able to be set globally on the bridge or on a per channel basis. 5. Blocking/Non-Blocking The API has both blocking and non-blocking function for putting a channel into a bridge. There is also a function for taking a non-blocking channel out of the bridge and returning control to another thread. I don't think I've missed anything... but if anyone has any questions or comments reply back and I'll address them. -- Joshua Colp Software Developer Digium, Inc. - "The Genuine Asterisk Experience" (TM) _______________________________________________ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev