[asterisk-dev] Bridging API

[Joshua Colp]

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)