[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