1. What happened this past year
2. GNU Bayonne 1.0 Introduction
3. What will Bayonne 1.0 have?
4. What has been dropped in 1.0?
5. What are Olorin and Babylon?
6. GNU Bayonne events in 2002
7. What is next
What happened this past year
Actually quite a bit happened this past year. We went thru two major
releases and with the help of OSDL and others we were finally able to
deliver high density digital telephony services thru GNU Bayonne using
To make GNU Bayonne more widely used, we had help from Kai
who did some excellent work getting CAPI 2.0 support to work for
One of the big changes in GNU Bayonne this year had been development of
XML services. These are being carried forward to their logical
in the 1.0 release, but we are getting ahead here.
At the start of the year we received the "Best new Enterprise
award from the Singapore Linux Conference. We have been trying to
live up to this award all year long!
This year I also had been serving as the communities elected
representative to the International Softswitch Consortium. This
involved a bit of travel and resulted in some interesting contacts. It
also perhaps most profoundly effected my decision to finally introduce
free software a softswitch application server, Olorin, to compliment
GNUCOMM softswitch effort.
Perhaps one of the most interesting and useful things to happen for GNU
Bayonne has been it's acceptance as a project in OSDL. This has
us with access to enterprise and carrier level hardware to develop and
test GNU Bayonne. This facility has been used somewhat minimally so
this year, especially since soon after it's availability late this year
had marched off to work on Bayonne 1.0, but I expect to see much
use of it occur during the next year.
The most important development however has been the increasing
acceptance of GNU Bayonne. This perhaps is represented in part by it's
acceptance in OSDL, but also in the use of GNU Bayonne in e-government
the State of Maine and similar commercial venues, and by the
of a Bayonne based unified messaging product at Linux World in San
However, all these things have been overshadowed by events in December,
leading to the introduction of GNU Bayonne 1.0, and the first
of Bayonne by a commercial carrier to deliver various dialtone services
starting next year.
GNU Bayonne 1.0 Introduction
During early 2002 we will be introducing the 1.0 release of GNU
This release and the ones that will be immediately prior have been
from an entirely new code base that was created starting in December.
This new code base is used to generate Bayonne, Olorin, and Babylon,
a single source package.
The plan for release of GNU Bayonne 1.0 will start with the transfer of
the new code base to public cvs on Savannah. This will be placed under
the "BayonneNG" module name in the Bayonne cvs repository on Savannah,
and should be in place at the time this document is distributed, or on
This new code base is drawn from entirely newly written code. The
server, including class hierarchy, has been reviewed and selectively
re-implemented from scratch over the month of December. Those features
that will be part of a final 1.0 release have been kept, and some
have been selectively abandoned.
The initial builds of Bayonne 1.0 will likely be labeled 0.9, and the
first 0.9 release will be distributed around the end of January. In
it will likely take all of January to bring the new server code to the
point where it is usable in a release. This will be followed by a
set of 0.99 releases, and the full 1.0 release of Bayonne, perhaps
May, where I hope I may be able to formally introduce it as part of a
Telephony WiP at SANE in the Netherlands.
The 0.9 release will immediately introduce the new Olorin and Babylon
servers which are also to become a standard part of Bayonne and the 1.0
package release. These servers are still in somewhat preliminary form,
and may not mature until mid-year. Perhaps the "2.0" release of
will include what one might consider to be the actual "1.0" release of
Olorin and Babylon, depending on how progress on testing and
occur in these two additional servers over the new year.
What will Bayonne 1.0 have?
To better support carrier class services and hardware, Bayonne has been
rewritten to support hot swap (cPCI) services. This allows Bayonne to
take ports or groups of spans selectively out of service into a standby
mode and return resources to the OS.
Perhaps by far the most important part of Bayonne 1.0 is what will
actually be introduced at "GNU/"LinuxWorld in NYC. What I will say of
at this time is that it is an entirely new framework for building and
supporting all forms of telephony media devices and that it will
change the way all telephony applications are written in the future for
free operating systems, not just for Bayonne. In fact, the
introduction of this framework was one of the principle reasons for a
complete rewrite of Bayonne to be undertaken at this time.
For testing purposes, it is now possible to execute Bayonne without any
special telephony hardware. A functional "dummy" device exists which
simulate hardware behavior and allow applications to be tested and
executed under keyboard control. If the machine has an OSS based sound
card, it will be used to perform audio processing operations on the
PC, and hence allow one to simulate behavior of Bayonne applications
demonstrate services without any telephony hardware.
Integration of Bayonne with PreViking based Infotel services is also a
major change for the 1.0 release. The Viking Infotel server will be
provide standard database access in much the way BayonneDB had been
intended for things like call detail records, for balance lookup on
System monitoring thru a tcp port connection will also become a
part of Bayonne 1.0. This will allow both command driven "shell"
to the Bayonne server's internal operation states, and the ability to
create a front-end gui to monitor running servers. Between system
monitoring and the ability to pre-test servers, it should be possible
more effectively deploy and debug both applications and running servers
the level needed for a commercial network operations center.
The use of XML in Bayonne has been extended for 1.0. Bayonne, Olorin,
Babylon will now parse an shared XML based "configuration document".
This document can either reside on the local file system as a /etc
or it can be fetched from an internal web server during startup. This
should allow one to globally configure a group of Bayonne, Olorin,
Babylon servers from a central server. Remote fetching of scripts and
voice libraries during startup is also being worked on.
To better support creation of dedicated commodity and embedded
applications, such as turnkey voice mail systems, it will soon become
possible to compile and build Bayonne servers in a "light" mode which
no XML support. This will be done by constructing a GNU Common C++
library without XML support. I am also looking at generating a further
function reduced GNU Common C++ build that will reduce the footprint of
Bayonne even further when so desired.
Another change is support for user scripting. User scripting enabled
anyone with a login id on a box running a Bayonne, Olorin, or Babylon
server to create and manage their own telephony application service
their own prompt library once they are added to the bayonne group by
system admin and by assigning number routing to such user services thru
Infotel, such as by DNIS, for example. This is conceptually similar to
how users might create personal web sites on an Apache server by
public_html folder in their home. This permits one to host telephony
"services" for outside users and easily create a telephony ASP even
without using XML.
Where in the past Bayonne has been distributed without prebuilt sample
applications, this will be changed starting with the 1.0 release.
Currently there are several different groups working on Bayonne
applications for both the current and the 1.0 release series, both in
US and abroad. Some of these we expect to demonstrate at
in NYC next month.
Perhaps the greatest single change in the whole project is that the
source tree has been simplified. It is now possible to intelligibly
where sources for various parts of Bayonne are without having to go
several directory levels.
FAX support is an interesting question that currently is being
in Bayonne 1.0. We have not supported FAX operations in the past
in conjunction with Hylafax, but we expect to do so directly sometime
the future. I am not sure if FAX support will make it in time for 1.0,
however. It may have to wait for "1.1".
Finally, GNU Bayonne is absorbing functionality from the PreViking
telephony server. PreViking, along with Infotel, and some other soon
be announced things, are GPL licensed telephony related projects that
sponsored by Telesave in the UK. Bayonne 1.0 will directly offer
functional services constructed thru scripting that match those
provided by PreViking, including debit calling and answering services,
will also offer some additional services related to building of ACD
systems, unified messaging, and hosting of voice commerce.
What has been dropped in 1.0?
I have chosen not to implement the Pika driver for the 1.0 release of
Bayonne. This is due to the fact that the card and software are not
actively maintained for GNU/Linux any longer.
There have also been a lot of odd ways of integrating Bayonne with web
services, including cgi wrappers, and even ssh stuff. All of this
has been removed. XMLRPC as provided thru the GNUCOMM Apennine server
will become the standard way to interact with a running GNUCOMM
whether from the web or other applications.
I am sure there are enough minor differences to confuse some. In fact,
one of the biggest problems is that the current project documentation
already well obsolete, even before the rewrite. Hence, the current
documentation, in effect, is being dropped.
What are Olorin and Babylon?
One of the changes not so visible has been how we restructured the
class hierarchy of Bayonne in the 1.0 series. The most striking change
that, like GNU ccScript, the entire processing state engine of GNU
is now represented thru a class extensible state machine that is now
in the primary server rather than having to be coded in each and every
driver, as was the case with the past.
This change has made it possible to directly derive alternate servers
of the common Bayonne source tree by changing some middle classes. The
result is that we now can build at least three servers out of a common
source package; Bayonne, Olorin, and Babylon. Both Olorin and Babylon
each share many common attributes with Bayonne, but have specific sets
functionality that is branched from the main Bayonne tree. Since they
share many of the same server base classes, they can also use the same
What Olorin does is provide a Bayonne-like server for next generation
telephone networks. It essentially provides a script driven
server that resides on top of a RTP media session stack. To manage
session control, a SIP stack is used in Olorin. Each RTP session has
instance of an Olorin interpreter just as each instance of a Bayonne
telephony port has a Bayonne interpreter. The dialects are similar,
though not identical. For example, Olorin provides access to "sdes"
source info, where such a concept does not exist in Bayonne. Olorin
requires no hardware and operates purely with VoIP telephone networks.
Olorin directly provides both media and application scripting services
one server. With Bayonne's support for XML parsing thru transcoding,
Olorin will act as a XML based softswitch application server.
Babylon is a media-free server that is used to provide pure application
scripting logic for traditional PBX systems. Babylon also differs from
Bayonne in that it provides extra support to implement the TOSI spec
third party call control and provides other provisions for standard
integration protocols. Babylon requires drivers that are aware of
and sometimes proprietary protocols that are used by PBX systems.
are often carried on serial links, and Babylon also can provide a means
taking these native protocols and making them network accessible as
as script driven. Babylon shares the state model of Bayonne and
where switching equipment often has it's own call control model,
derived from CSTA. This makes Babylon drivers far more complex than
Collectively, Bayonne, Olorin, and Babylon provide application services
GNUCOMM for both current and next generation telephone systems. They
are to be the foundation of telephony services in GNU Enterprise and
packages that reflect GNU Enterprise modules will also be created as
of GNU Bayonne, such as GNU Bayonne Customer Relations Management,
will do telephony operations related to that portion of GNUe.
GNU Bayonne Events in 2002
I have been kindly asked by Greg Herlein to run this year's Telephony
at next year's GNU/LinuxWorld in NYC on Thursday night. I also happen
be speaking at GNU/LW at the DotGNU panel on Wednesday as I happen to
chair that project, and will generally be around the GNUCOMM booth in
.org pavilion where I and others will be demonstrating GNU Bayonne old
and new, and the "other" thing that should be introduced then.
In May I currently hope to return to the Netherlands to give a BoF
WiP on GNU Telephony and GNUCOMM as a whole at next year's SANE
conference, as that should be the right time to distribute the final
Bayonne 1.0 release.
In July I expect to be back in France to speak at next year's LSM
to be held in the second or third week of July at the University of
Bordeaux. I expect it is likely I will be speaking both about GNU
and DotGNU, as we will have a gathering of the DotGNU steering
during the LSM.
What is next
Now that GNU Bayonne is getting close to 1.0, we can start looking to
where we wish to take telephony application services in the future with
free software. In this sense, three projects will become ever
more intermingled with the future of GNU Bayonne; the GNU project
as a whole, phpGroupWare and by extension DotGNU, and GNU Enterprise.
The role of GNU Enterprise and GNU Bayonne had been addressed before,
Bayonne replaced the EWOK component of GNU Enterprise. This role will
become more important as we focus more on delivering applications with
Bayonne. We do intend to deliver applications that are integral with
those of GNU Enterprise where GNU Enterprise requires telephony
as well as providing general enterprise level telephony application
phpGroupWare represents how we wish to make GNU Bayonne usable as part
everyday life for the enterprise worker. By enabling XMLRPC support
Apennine and it's future decedent, we expend to enable things like
the phpGroupWare address book dial out to people using Bayonne,
or Olorin, depending on the user's enterprise environment. Another big
area left to be explored is delivery of unified web based messaging and
GNU Bayonne voice mail thru phpGroupWare.
Finally, GNU Bayonne is, of course, part of the GNU project. This
we should work better as a natural part of GNU, and look at ways that
other parts of GNU can work with GNU Bayonne. Supporting guile for TGI
applications is one way we can do this. Supporting pnet as part of GNU
Bayonne is another way, and we do expect to provide a pnetlib framework
for providing telephony enabled web services as an effort related to
Our mission in GNUCOMM as a whole is to provide and standardize
services for the individual user, for the enterprise, and for
carriers, under free software. For this reason, GNU Bayonne will
to evolve as the standard telephony application services platform of
Any questions or comments can be addressed to David Sugar