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
begin:vcard
fn:David Sugar
n:Sugar;David
org:GNU Telephony
adr:;;;;;;USA
email;internet:[EMAIL PROTECTED]
x-mozilla-html:FALSE
url:http://www.gnutelephony.org
version:2.1
end:vcard
_______________________________________________
Bayonne-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bayonne-devel
