[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GNUe]Notes on Bayonne integration development roadmap...

From: David Sugar
Subject: [GNUe]Notes on Bayonne integration development roadmap...
Date: Thu, 29 May 2003 09:29:06 -0400
User-agent: KMail/1.5

This summarizes some areas of current Bayonne development related 
to the upcoming 1.3 release and beyond:

* External Bayonne Integration Scripting

Traditionally Bayonne scripting has dealt with control of individual call
sessions connected to telephony ports.  With the 1.3 release of Bayonne,
a new and external bayonne "scripting" shell will be introduced.  The
external bayonne shell will allow one to create scripts that interact
externally with and that are context are of the running state of a
bayonne server.

External scripting will allow one to create scripts that not only manage
the server as a whole, but that can also start and externally manage
running bayonne call sessions.  This could be used to create application
scripts that launch concurrent call sessions to do outbound dialing,
either from the shell or a cronjob, for example, and manage the results
of the operation. 

But there is more.  The external scripting language can be used to
output a valid html document and may be ran directly as a cgi.  This
allows one to easily create cgi apps that directly interact with a
bayonne server and output results from bayonne operations to a user
through the web.  This will depreciate the clumsy "wrapper" for
injecting commands from cgi into Bayonne through an exec.

The external scripting can also be used to generate and deliver mime 
attached email through sendmail, in formats and with content under 
script control.  Email template scripts depreciate the smtp and vpim 
module, as their behavior can now be simulated through external 

External scripting will also be invokable from the Bayonne scheduler.  
This will allow Bayonne's job scheduler to be used in a complete 
solution rather than using cron.  External management scripts will also 
be launchable from internal Bayonne scripting, and from soap through 
Apennine.  Bayonne scripting could also be used to write "libexec" 
applications, although doing so externally may be redundant.

Bayonne external scripting is intended to enable scripting of any system
resource or service that needs to interact with a Bayonne server.  It
may in the future support agi and direct supervisory application
integration between Bayonne and Asterisk, for example.  Another 
possibility is a "mod_bayonne" for Apache that internalizes Bayonne cgi 

* Apennine returns

Appenine will soon be back, and is now being built from gsoap, rather
than from xmlrpc.  Apennine will offer authenticated access to Bayonne
services through "soap", and will support soap serverlets that can then
be created to support specific bayonne applications.  Authentication of
user level access to user specific resources and preferences will be
possible.  For example, a Bayonne unified messaging platform may make
use of a unified messaging apennine applet that allows users to
manipulate their individual voice mailbox settings.

* Python and Bayonne

A separate project is being chartered to work specifically on python 
bayonne issues.  The resulting package will be known as "pybayonne".  
The first step will be supporting a python plugin that allows python to 
integrate with bayonne much the same way the new external scripting 
does, thus enabling one to create external integration applications in 
python.  Another area of development will be in supporting python's use 
through Bayonne's new "shelled" libexec facility to allow one to script 
call flow operations directly in python.

* Giza speech recognition services

Work has also been done on creating speech recognition services in Bayonne 
using cmu sphinx.  Asr integration will be in the form of an external server 
which  Bayonne will be able to route audio to.  It is possible other kinds of
routed voice integration will be done in the future, including feeding

reply via email to

[Prev in Thread] Current Thread [Next in Thread]