Re: [Bayonne-devel] New Server Features

[David Sugar]

As only a few people have seen or tried to work with the new server, and 
since you asked, I thought I would comment on its key architectural 
features:

First, no, it is not directly based on any prior or existing Bayonne 
code, whether in stable or testing snapshots.  It is all new code with a 
short history over a number of weekends inclusive to this year.  It is 
also radically feature reduced, but does use some key Bayonne 
architectural concepts.

The use of locks and blocking have been redone to assure maximum SMP 
performance.  In fact, many operations where excessive recursive mutex 
locks were once used are now performed either lock free or with minimal 
locking.

The server uses a single timeslot table, and can allow for multiple 
drivers to to be mapped together in a peer fashion.

Ports from arbitrary drivers can peer audio, queue and disperse 
signaling directly.  In fact all normal join operations are now outer 
peer audio operations.  There are some drivers which will be unable to 
peer, either do to high latency, use of TDM, or poor vendor design.

The functionality needed to code a driver has been greatly simplified.

A new continues audio processing model is being worked on which will 
soon allow those drivers which will do continues audio to perform 
background music automatically, overlay audio, and other special 
effects.  This will allow Bayonne to offer streaming audio (and video) 
services over the internet in the future as well.  This is something I 
want to free some time to work further on, which is another reason I 
would like to do an early release to get more people involved.

The scripting language has been greatly simplified, has an enforced at 
compile time specification, and consistent use of symbol scope.  It also 
has been tuned for better execution performance.

The entire driver infrastructure and Bayonne state machine system 
presents itself as a linkable library which can be used to rapidly build 
other kinds of telephony servers.

Drivers that currently do work include SIP (with a proxy server), the 
voicetronix analog card family, the soundcard driver for testing, and 
openh323.  Curiously the openh323 driver works well with gnomemeeting 
but freezes with ohphone because something internal to openh323 refuses 
to give up a mutex lock.  The dialogic driver is nearly fully coded but 
not yet demonstratably functioning.

Target platforms that function today include GNU/Linux, MacOSX, and 
FreeBSD.  Other BSD varients should work also.  There is active w32 
development, and something generally functional beyond the link 
libraries there will not be very far off.

The biggest problem with building Bayonne SIP is that you need to use 
CVS versions of osip and exosip though the install guide explains this 
well.  The biggest problem with openh323 is it seems fussy about 
compiling with older releases, particularly on older distros.

I suppose overall there could be worse 0.1.0 releases, if I do an early 
release at this point...

Ambar Roy wrote:
> > I looking for opinions on whether it would be better to do an early 
> > release of the new server so that more people can effectivily 
> > begin to 
> > work on it, or to wait until it is more complete.
>
> Hi David,
>
> I think that making a release would get more people to work on it. BTW what
> is the status with the new server? Are you starting with a new
> codebase/architecture or are you building upon the existing codebase? In
> what ways is the new release going to be different from the current
> development snapshot or the current stable release?
>
> Regards,
>
> Ambar Roy

dyfet.vcf
Description: Vcard