[asterisk-dev] Channel Bridging

[Kaloyan Kovachev]

 It will probably require lots of changes, but ... 
 What if there are few "bridging engine" threads (configurable to handle the
load of the system with regards on available resources). When there is a new
call to be bridged it should subscribe for bridging to the least loaded
engine, which will handle it from that point. 
 The engine should not do the actual frame exchange/mixing in any of the
methods, but based on the number of channels, channel flags, features and
received frame type may decide which bridging method to call (attach), to
actually exchange the data or not to do so, when muted or suspended. This way,
even in a conference, when there are just 2 channels to bridge, it will simply
pass frames. If it's FAX/DTMF frame may process or pass it. 
 Even local services (parking, MOH, VM, Echo, milliwatt ...) could be treated
as a normal call leg in this case, so there could be just one instance for
each MOH class used instead of one per channel on hold. 
 The engine may check regulary if there is a new data in the channel, which
should be OK even with silence suppression. The data may be passed to/from an
independent from the channel configurable jitter-buffer, echo canceler and/or
CNG, then to the other channel(s). 
 As the bridge will create its config upon subscription for each channel, the
features (as timeout and forward being enabled/disabled) won't be lost and may
keep them until the last channel is closed or even some time afterwards (may
also keep the data until all registered CDR engines have successfully stored
their records so no record will be lost even if the database wasn't available
for few minutes) 
 The engine will not be closed even if there are no calls to bridge, but will
wait for the next call. 
 
just my 0.02


On Sat, 25 Feb 2006 09:56:43 -0500, SteveK wrote
> > 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.
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev