[asterisk-dev] Channel Bridging

[Joshua Colp]

Hellllllllllo Folks,  
   
I thought I'd give a nice email to the list about some stuff I've been pondering/mucking with in regards to channel bridging.  
   
As it is right now, channel bridging is spread out across a few places -- enough that it gives me a headache just to think about it. We've got native bridges happening, generic bridges happening, and bridges with features, and who knows what else. In order to advance we need to come to a conclusion on how exactly we want bridges to work and what features they need to have. The rest of this post is my thoughts and ideas (some of which have already been implemented in my own testbed).  
   
1. A bridge is a method of combining channels (even more then 2) together in order to exchange or mix frames.  
   
For a bridge consisting of more then 2 channels we can use zaptel pseudo channels to do audio mixing, while we would need to find another method of exchanging other frames for things such as DTMF.  
   
2. A bridge should have it's own operating thread which is able to be manipulated outside of itself by other threads.  
   
This is rather easy in my opinion. When a bridge is allocated, simply start up the corresponding thread to the type of bridge but since there would be no channels present the bridge could then go into a sleeping state until awoken by the addition of a channel.  
   
3. A bridge can have features activated on it to do various things (timeout for example).  
4. A bridged channel can have features itself, such as one way audio muting.  
5. A bridged channel can temporarily be suspended, but not removed, from a bridge so it can be handled by another thread.  
   
The idea here is that you would set a flag on the bridged channel and wake up the bridge thread. The bridge thread would then no longer handle this channel and control would be given to whomever suspended it. Once they did whatever they want to do, unsuspended it, wake up the bridge thread, and it goes back into doing it's thing in the bridge.  
   
6. The termination of a bridged channel does not cause a bridge to terminate unless this feature is activated. (*COUGH* no more masquerading *COUGH*).  
   
This would be rather cool because the way we do things now for attended transfers is rather ugly. One channel masquerades into another in a process that only 2 people in the world really understand. Using this new bridging concept one channel would leave the bridge, and another channel would join the bridge.  
   
Thoughts? Opinions? Concepts? Ideas? Additions?  
   
Joshua Colp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20060224/d38e3cac/attachment.htm