This year in GNU Bayonne

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
Dialogic hardware.

To make GNU Bayonne more widely used, we had help from Kai
Germaschewski
who did some excellent work getting CAPI 2.0 support to work for
European
ISDN users.

One of the big changes in GNU Bayonne this year had been development of
XML services. These are being carried forward to their logical
conclusion
in the 1.0 release, but we are getting ahead here.

At the start of the year we received the “Best new Enterprise
Application”
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
actually
involved a bit of travel and resulted in some interesting contacts. It
also perhaps most profoundly effected my decision to finally introduce
as
free software a softswitch application server, Olorin, to compliment
the
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
provided
us with access to enterprise and carrier level hardware to develop and
test GNU Bayonne. This facility has been used somewhat minimally so
far
this year, especially since soon after it’s availability late this year
I
had marched off to work on Bayonne 1.0, but I expect to see much
greater
use of it occur during the next year.

The most important development however has been the increasing
commercial
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
by
the State of Maine and similar commercial venues, and by the
demonstration
of a Bayonne based unified messaging product at Linux World in San
Francisco.

However, all these things have been overshadowed by events in December,
leading to the introduction of GNU Bayonne 1.0, and the first
acceptance
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
Bayonne.
This release and the ones that will be immediately prior have been
drawn
from an entirely new code base that was created starting in December.
This new code base is used to generate Bayonne, Olorin, and Babylon,
from
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
January 1st.

This new code base is drawn from entirely newly written code. The
entire
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
features
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
fact,
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
final
set of 0.99 releases, and the full 1.0 release of Bayonne, perhaps
around
May, where I hope I may be able to formally introduce it as part of a
GNU
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
Bayonne
will include what one might consider to be the actual “1.0” release of
Olorin and Babylon, depending on how progress on testing and
documentation
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
it
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
probably
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
can
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
local
PC, and hence allow one to simulate behavior of Bayonne applications
and
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
used
provide standard database access in much the way BayonneDB had been
intended for things like call detail records, for balance lookup on
debit
transactions, etc.

System monitoring thru a tcp port connection will also become a
standard
part of Bayonne 1.0. This will allow both command driven “shell”
access
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
to
more effectively deploy and debug both applications and running servers
to
the level needed for a commercial network operations center.

The use of XML in Bayonne has been extended for 1.0. Bayonne, Olorin,
and
Babylon will now parse an shared XML based “configuration document”.
This document can either reside on the local file system as a /etc
file,
or it can be fetched from an internal web server during startup. This
should allow one to globally configure a group of Bayonne, Olorin,
and/or
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
telephony
applications, such as turnkey voice mail systems, it will soon become
possible to compile and build Bayonne servers in a “light” mode which
uses
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
with
their own prompt library once they are added to the bayonne group by
the
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
placing a
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
the
US and abroad. Some of these we expect to demonstrate at
GNU/LinuxWorld
in NYC next month.

Perhaps the greatest single change in the whole project is that the
entire
source tree has been simplified. It is now possible to intelligibly
find
where sources for various parts of Bayonne are without having to go
thru
several directory levels.

FAX support is an interesting question that currently is being
re-visited
in Bayonne 1.0. We have not supported FAX operations in the past
except
in conjunction with Hylafax, but we expect to do so directly sometime
in
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
to
be announced things, are GPL licensed telephony related projects that
are
sponsored by Telesave in the UK. Bayonne 1.0 will directly offer
functional services constructed thru scripting that match those
currently
provided by PreViking, including debit calling and answering services,
and
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
cruft
has been removed. XMLRPC as provided thru the GNUCOMM Apennine server
will become the standard way to interact with a running GNUCOMM
services,
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
is
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
primary
class hierarchy of Bayonne in the 1.0 series. The most striking change
is
that, like GNU ccScript, the entire processing state engine of GNU
Bayonne
is now represented thru a class extensible state machine that is now
found
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
out
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
of
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
plugins.

What Olorin does is provide a Bayonne-like server for next generation
telephone networks. It essentially provides a script driven
application
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
an
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”
RTP
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
in
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
for
third party call control and provides other provisions for standard
switch
integration protocols. Babylon requires drivers that are aware of
native
and sometimes proprietary protocols that are used by PBX systems.
These
are often carried on serial links, and Babylon also can provide a means
of
taking these native protocols and making them network accessible as
well
as script driven. Babylon shares the state model of Bayonne and
Olorin,
where switching equipment often has it’s own call control model,
sometimes
derived from CSTA. This makes Babylon drivers far more complex than
Bayonne ones.

Collectively, Bayonne, Olorin, and Babylon provide application services
in
GNUCOMM for both current and next generation telephone systems. They
also
are to be the foundation of telephony services in GNU Enterprise and
packages that reflect GNU Enterprise modules will also be created as
part
of GNU Bayonne, such as GNU Bayonne Customer Relations Management,
which
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
BOF
at next year’s GNU/LinuxWorld in NYC on Thursday night. I also happen
to
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
the
.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
and/or
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
event,
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
Bayonne
and DotGNU, as we will have a gathering of the DotGNU steering
committee
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
itself
as a whole, phpGroupWare and by extension DotGNU, and GNU Enterprise.

The role of GNU Enterprise and GNU Bayonne had been addressed before,
when
Bayonne replaced the EWOK component of GNU Enterprise. This role will
become more important as we focus more on delivering applications with
GNU
Bayonne. We do intend to deliver applications that are integral with
those of GNU Enterprise where GNU Enterprise requires telephony
services,
as well as providing general enterprise level telephony application
services.

phpGroupWare represents how we wish to make GNU Bayonne usable as part
of
everyday life for the enterprise worker. By enabling XMLRPC support
thru
Apennine and it’s future decedent, we expend to enable things like
having
the phpGroupWare address book dial out to people using Bayonne,
Babylon,
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
means
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
GNU
Bayonne.

Our mission in GNUCOMM as a whole is to provide and standardize
telephony
services for the individual user, for the enterprise, and for
commercial
carriers, under free software. For this reason, GNU Bayonne will
continue
to evolve as the standard telephony application services platform of
the
GNU project.

Any questions or comments can be addressed to David Sugar
sugar@gnu.org.