[asterisk-dev] Channel Bridging

SteveK stevek at stevek.com
Sat Feb 25 07:56:43 MST 2006


> 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.
>
>

Personally, if you're going to do this inside asterisk, I'd do multi- 
party bridging the same way I do it in app_conference, and _not_ with  
zap pseudo channels.  This works with complete frames, and can be  
much more efficient.

But, I wouldn't use the exact same mechanism for mixing multiple  
parties that is used for mixing just two channels, because there is  
necessarily a latency penalty for doing so (this applies mainly to  
VoIP channels):  A 2 party bridge can simply pass frames across as  
they are received, with no need for synchronization or proper  
ordering:  A conference requires that the mixing be done  
synchronously, with frames in-order (i.e. a jitterbuffer needs to be  
present on incoming channels, and the mixing must be synchronous).

I do agree that it would be good if the API for two-party and  
multiparty bridges were the same, though, but two-party bridges are  
such a common case that it makes sense to perform them optimally, and  
not use the lowest-common denominator for multi-party conferences.



More information about the asterisk-dev mailing list