[Bayonne-devel] Building turnkey solutions with Bayonne 2

[David Sugar]

Bayonne has historically been easy to use in creating ad-hoc and
specialized enterprise voice applications.  The use of a scripting
engine and the server being very scripting and application centric, even
for configuration and control, has I think helped this use.  I believe
many of these same attributes have in the past tended to make Bayonne
rather difficult package in pure turnkey and dedicated solutions.

In Bayonne2 I have looked at resolving this issue in several ways.  In
the most extreme form, Bayonne2 can now be decapitated, and the new
libbayonne used with an entirely new server/application environment.
This allows reuse of Bayonne drivers and management frameworks, as well
as the core call processing engine, while offering the ability to build
special purpose servers that might be better suited for some types of
turnkey or specialized applications.  This ability will be further
explored in several packages that use libbayonne and adapt it for xml,
and servers that are more routing centric rather than application
centric, such as troll gateways.

Another solution, which has been quietly explored through the 0.8 releases,
is the use of an alternate provisioning file.  The idea behind this is that
one should be able to take a generic, even pre-build distribution of a 
bayonne
server, such as one might find in a debian distribution, wrap it with some
scripts, maybe a plugin, and thereby build and deploy a complete solution.
To do this, several things had to happen.

To do turnkey solutions, the scripting language had to be maintained
consistently between different arbitrary versions.  In the past this was
not rigorously enforced.  This was in part because when Bayonne was
started, there was no clear or certain idea as to what the scripting
language would eventually need to do.  So it evolved with Bayonne.  In
Bayonne2, we now have a good idea of how scripting should be used, and
so it has been possible to define it correctly at the earliest releases.
It is certainly possible to see script functionality expanded with new
releases, but only so long as existing commands are fully retained.

The idea behind a provisioning file (/etc/bayonne/provision.conf) was
based on another idea to simplify turnkey products.  The provisioning
file is meant not to be user edited, but rather as a separate configure
file that would be created by the provisioning/configuration system of
some turnkey product.  The idea was to have a separate place where an
automated configure file could be used to define and override server
properties as needed by turnkey products.  This keeps a clean separation
between user editable configure files, and those that are part of a
turnkey product if present. This I believe will also make it easier to
take generic and pre-packaged versions of Bayonne, such as might be
found in a debian repository, which may include default or generic
configure files, and still easily merge that into a turnkey solution.

Another area that may pose some difficulties is that Bayonne is
scripting centric.  Even routing information is often carried in
scripting.  This is not a problem for creating turnkey applications that
might use a front-end script and external meta-data driven sources for
routing, such as a subscriber voice mail server or debit system that has
an external subscriber database, or to create a dedicated sip voice mail
system through turnkey provisioned with scripts that integrate for
example with sipxpbx.  However, some types of routing centric
applications will still be hard to do in Bayonne alone, either because
the configuration system for such solutions will either need to also
generate scripts, or scripts will need to be manually maintained.
Solutions to the latter issue will be explored in Troll and a proposed
descendant of Troll that I think will become very popularly used.

dyfet.vcf
Description: Vcard