Re: [Bayonne-devel] web article about Bayonne

[Ambar Roy]

Hi David,

Where should I look to learn more about bayonne? Is there any documentation
on the architecture of bayonne? Or should I start going thru the source and
figure things out myself? It looks like bayonne does most things I am
looking for in an IVR platform.

Ambar Roy


> Ambar Roy wrote:
> > I was just wondering what features I would love to see in bayonne and I
> > came up with quite a long list
> > (assuming these things are not already there):
> > 1. Support for ASR using an external speech rec library (commercial or
> > open source)
>
> We initially tried some stuff with Sphinx, but it was complex, driver
> specific (and specific to sphinx), and rather hard to maintain.  Yes,
> this area is still very open to additional ideas and work.
>
> > 2. Ability to handle high density configurations with 4-10 E1 links per
> > machine
>
> We actually have had Bayonne servers tested up to 28 spans (T-3) in the
> past.
>
> > 3. Ability to have multiple indipendent applications installed at the
> > same time, so that adding/removing applications does not involve a
> > server restart.
>
> This is done today through ccscript.  The entire application script base
> can be recompiled while the server is live and calls are in progress.
> All current calls continue normally under the existing application
> scripts, and when all they all have exited, the old scripts are purged.
>  New calls are meanwhile offered the newly compiled script set.
>
> > 4. On the fly change in configuration esp if there can be a way to do
> > this w/o affecting call traffic to the machine.
>
> For scripts this is possible to do as noted above.  Some aspects of
> server configuration, particularly in defining trunk groups, is
> currently rather resistent to any dynamic change.  I have some thoughts
> about this, in particular related to moving some configuration
> definitions into the scripting language itself, as that already has an
> excellant infrastructure for resolving dynamic changes as noted.
>
> > 5. Monitoring of line status so that i can tie in alerting applications
> > to inform me in case links go down/come up. Ports freeze, etc.
>
> Bayonne currently broadcasts port states over a udp packet.  There are
> monitoring tools, including one written in Java, already to do some
> basic things like this.  There is also the baysite utility, written
> around the fox toolkit.
>
> > 6. Support for ISDN, R2 & SS7 signalling using dialogic boards.
> > Prefferably using GlobalCall PDK/ICAPI drivers for R2/CAS signalling..
>
> I think the globalcall driver support should let you do this now...
>
> > 7. Ability to remotely administer the server over a simple web
interface.
>
> There had been experiments with a webmin integrated module, but nothing
> that was either standardized or broad enough to really do this properly
> as yet.  There is a tcp monitor application allowing one to connect
> remotely with tcp and manage it from a remote shell.
>
> > 8. Reliable and fast connectivity to external apps.
>
> Well, one can build a dso module.  That is fastest :).  Actually there
> had been some changes made in the testing branch for tgi that I do want
> to make as a change in the stable release, in particular the use of unix
> peer sockets rather than pipes, as the buffering for external requests
> is much better.
>
> > 9. Have an easy to understand and use async code path, so that we can
> > have a realtime thread that schedules time intensive operations
> > asynchronously. Currently we write to and read files to achieve this.
> > But using files is not very efficient :-( For things like database
> > queries and network operations, it is real convinient to have a seperate
> > execution path where one can perform long tasks. Support for this in
> > native scripting format would be neat too.
>
> In Bayonne dso plugins, this is possible, in fact, required to be done.
>  For example, the dso plugins for sql database queries operate in this
> manner.
>
> > 10. voice xml support. I have not yet looked much into voice xml, but it
> > seems to be getting quite popular with IVR platform vendors.
>
> There was some experiments with XML.  In fact, in all the 1.x releases,
> consistently XML and SQL support were in an odd way tied together.  The
> XML implimented was a cousin to CallXML.  The whole infrastructure was
> very complex and rather unwieldy.  I would like to remove XML completely
> from Bayonne itself (even in testing it is already gone), and perhaps
> introduce a seperate and different server specifically for XML that
> re-uses Bayonne's driver infrastructure.
>
> > 11. Conferencing support
>
> This exists in some rather initial form in the current Dialogic (and
> Globalcall) drivers in the latest 1.2.x releases.  It also existed in
> some initial form in the depreciated pika drivers.
>
> > 12. Support for hot swap features provided by cPCI hardware from various
> > vendors- Probably not very important
>
> The driver states and meta-data needed to manage this would not be very
> large.  The current state model would be excellant for introducing this.
>
>
> > Ambar Roy
> >
> >     ----- Original Message -----
> >     *From:* Julien Chavanton
<mailto:address@hidden>
> >     *To:* David Sugar <mailto:address@hidden> ; Ambar Roy
> >     <mailto:address@hidden>
> >     *Cc:* address@hidden <mailto:address@hidden>
> >     *Sent:* Tuesday, April 05, 2005 8:21 PM
> >     *Subject:* RE: [Bayonne-devel] web article about Bayonne
> >
> >
> >
> >     But I personally think that things are improving,
> >
> >     I have a running version that handle 40 000 calls/day.
> >
> >
> >
> >     I trust CommonC++2 & Ccscript, they seem to be bug free.
> >
> >     As long as this is reliable drivers should not be too hard to debug.
> >
> >
> >
> >
> >
> >     Features and expectation I am looking for:
> >
> >
> >
> >     -The multiple drivers support may be delayed.
> >
> >
> >
> >     -Even if we are working a lot on Globalcall this let us test the
> >     core of Bayonne in the mean time.
> >
> >
> >
> >     -I think H.323 and SIP will soon become more and more important I
> >     think Bayonne will be really interesting as an IVR VOIP server.
> >
> >
> >
> >     -Reliable Database support from Ccscript is a key feature, the one
> >     currently in Bayonne is still having bug, I have made my own and you
> >     know this is not something complex and does bring a lot of
> >     Interactivity possibility.
> >
> >
> >
> >
> >
> >     Conclusion, I think ?keep it simple? is the main lead we shall
> >     choose, there is already enough feature to debug.
> >
> >     If we can tell that most of the basic features are working as it is
> >     the case currently; Bayonne should be easier to start with and more
> >     people will start using it and help.
> >
> >     With the Lucas How-To it is now quite easy to install and configure
> >     Bayonne.
> >
> >
> >
> >     Any body is having problem with Dialogic Globalcall Drivers in
Bayonne?
> >
> >
> >
> >     Julien
> >
> >
> >
> >
> >
> >     -----Original Message-----
> >     From:
> >     address@hidden
> >
[mailto:address@hidden
> >     On Behalf Of David Sugar
> >     Sent: April 5, 2005 9:40 AM
> >     To: Ambar Roy
> >     Cc: address@hidden
> >     Subject: Re: [Bayonne-devel] web article about Bayonne
> >
> >
> >
> > Hash: SHA1
> >
> >
> >
> > I had been rather quiet because until very recently even I had not
> >
> > reached any final decision on what we would be doing going forward.
> >
> > Perhaps I have been quiet for far too long.
> >
> >
> >
> > Originally we had some problems starting in 2003, when we had a party
> >
> > interested in producing an analog phone system around voicetronix
> >
> > hardware.  This resulted in a lot of time and interesting development
> >
> > spent on that, but at the expensive of loosing focus on what Bayonne is
> >
> > and on other things that would have been more valuable to people, such
> >
> > as completing the then original openh323 driver that one contributor
> >
> > started.  Of course, we later learned we could not use that original
> >
> > openh323 driver anyway, because the person who submitted it later signed
> >
> > agreements with another project which claimed ownership over his
> > past work.
> >
> >
> >
> > Around the start of 2004, new work was split into two trees, a testing
> >
> > tree I started both to try and restore a better focus on what Bayonne
> >
> > is, and based on new work and recommendations of people who were later
> >
> > involved on the second tree.  This second tree was already then largely
> >
> > complete, and included a new solid implementation of the openh323, and a
> >
> > new aculab driver.  The aculab driver I had no means to test, and since
> >
> > the new tree was being maintained and heavily tested internally by
> >
> > others with such facilities, I agreed to promote that new tree as the
> >
> > new stable release.  Given that, I modified the existing testing tree to
> >
> > much more closely match the second stable tree, and bring the openh323
> >
> > driver that I could test to match the second tree, to allow for wider
> >
> > testing of the tree and at least of that new driver in the process, and
> >
> > later as a place to get a sip driver going that could then easily
> >
> > migrate back to the now similar future stable branch.
> >
> >
> >
> > In that the second stable tree was essentially complete, I was asked to
> >
> > discontinue the testing tree so as not to confuse users with two trees
> >
> > with the introduction of the then promised release of the new stable
> >
> > tree.  Of course around that time I also was sick part of 2004 with
> >
> > Pneumonia, and afterward for other medical reasons, I could not travel
> >
> > for much of the rest of last year.  Many of the normal events and
> >
> > activities I do which involve Bayonne I was completely unable to perform
> >
> > or attend.  I also moved, and I was kept very busy much of the remainder
> >
> > of the year in other areas.  For the most part I was generally
> >
> > unavailable to many people most of last year as a result.  For that I
> >
> > assume full responsibility.  Of course, in that commitments were made to
> >
> > me about introducing the new stable branch, and I completely trusted in
> >
> > those commitments, I did not interfere in that process.  I had
> >
> > considered appointing an interum maintainer as part of that release
> >
> > which never happened.  As a result, nothing was accomplished in 2004.
> >
> >
> >
> > As it was rather clear by the end of 2004 that those commitments were
> >
> > not going to be fulfilled, I used what rather limited time I then had
> >
> > available to work with a number of people who were maintaining existing
> >
> > production sites, and particularly the excellent people at WS Wireless
> >
> > in Bologna.  Together, we worked on changes needed to improve and better
> >
> > support those using the last stable release, and bring it forward to
> >
> > support current builds of Common C++ and other updated and bug-fixed
> >
> > libraries, a process that continues to this day.  These changes were
> >
> > limited either explicitly to specific bug fixes (particularly in the
> >
> > dialogic drivers, which they use) and the completion of one feature that
> >
> > was originally started in the testing branch; audio conferencing support
> >
> > in the dialogic drivers.
> >
> >
> >
> > As I found myself at the start of the year again the sole maintainer of
> >
> > Bayonne, I had a number of possibilities going forward, and rather
> >
> > limited time for any option I might choose.  Certainly the simplest
> >
> > option would have been to discontinue Bayonne.  But I felt I could not
> >
> > do that especially after the incredible help and support Aymeric gave me
> >
> > early this year with the SIP driver, and with the continued support I do
> >
> > get from people in the community, and we definitely do have one, such as
> >
> > Luca, as well as that of people from companies like the WS Wireless
> >
> > people, and Gerry Gilmore from Intel.
> >
> >
> >
> > The first option going forward was to push the existing stable branch
> >
> > forward and perhaps backport some other things from the testing branch.
> >
> >  Of course, that branch had a lot of odd inconsistencies from the effort
> >
> > put into supporting analog phone system cards and from the then rather
> >
> > fluid nature of the ccscript core language itself.  It also suffers from
> >
> > one other key Bayonne limitation; by pushing so much functionality down
> >
> > to the driver, and with different people involved in initially creating
> >
> > new drivers, each driver now has a very unique design pattern.  Hence,
> >
> > each new driver added tends to exponentially add to the difficulties in
> >
> > maintaining the system as a whole.  This is fine when each driver has
> >
> > someone separate to maintain it, but becomes impossible when a large
> >
> > number of the drivers have to be maintained without direct access to
> >
> > every piece of hardware used, and where each driver must then be
> >
> > verified for every change being made.
> >
> >
> >
> > A second possibility would have been to promote and continue developing
> >
> > the testing branch.  But while a lot of forward looking work was started
> >
> > in it, all that was stopped and then abandoned last year, as it was
> >
> > re-made to resemble the new stable branch that never appeared.  Hence,
> >
> > many key limitations do remain unaddressed, and in some respects are
> >
> > worse than even the stable branch, as it has a larger body of drivers
> >
> > each with even more different design patterns.
> >
> >
> >
> > The third option was to finally radically simplify Bayonne and refocus
> >
> > on what it is supposed to actually do, much more so than what work was
> >
> > in progress in the testing branch before being stopped.  As just one
> >
> > example, while a lot of work had been done in the testing and missing
> >
> > new stable release on loading multiple drivers, each driver maintained
> >
> > in it's own way it's own managed timeslot segment of drivers, each coded
> >
> > in their own way; instead, it would be much simpler to assign all loaded
> >
> > drivers over a single contigues timeslot map, to have them all share
> >
> > common base classes which run the same core state machine code, to have
> >
> > all common audio processing peered in the common timeslot base rather
> >
> > than implemented in very different ways in each driver, and to finally
> >
> > have a common design pattern for all drivers, including for the
> >
> > difficult process of handing off thread deaths out of the dying thread's
> >
> > context, which is something that is done in a different and amazingly
> >
> > complex way in each and every driver currently.  But this would take
> >
> > some time, and even further freeze other activities until completed...
> >
> >
> >
> > Ambar Roy wrote:
> >
> >>>>I wrote an introduction to Bayonne and IVR services for the web
> > megazine
> >
> >>>>linuxfocus (http://www.linuxfocus.org)
> >
> >>>>
> >
> >>>>it's in english:
> >
> >>>
> >
> >>> http://www.linuxfocus.org/English/April2005/article372.shtml
> >
> >>>
> >
> >>>>and italian:
> > http://www.linuxfocus.org/Italiano/April2005/article372.shtml
> >
> >>>>
> >
> >>>>the goal is, of course, to promote Bayonne's use in phone services
> >
> >>>
> >
> >>> Hi Luca,
> >
> >>>
> >
> >>> I read the english version. Excellent Article!
> >
> >>>
> >
> >>> I have been evaluating bayonne for some time and here are some
> > reasons why I
> >
> >>> am not being over enthausistic about using bayonne in production
> >
> >>> environments:
> >
> >>>
> >
> >>> a. I hardly see any developer activity on bayonne. I have been a
> > member of
> >
> >>> bayonne-devel list for some time now and the message traffic is
> > almost non
> >
> >>> existant.
> >
> >>>
> >
> >>> b. I have seen that most people's queries on bayonne seem to go
> > un-answered.
> >
> >>>
> >
> >>> c. I do not see any real community behind bayonne. I have been a
> > member of
> >
> >>> this list for the past 3 months and the only active members seem to be
> >
> >>> yourself, David and Julien. What happened to everyone else?
> >
> >>>
> >
> >>> d. I have no clue as to how stable is bayonne's connectivity to
> > telephone
> >
> >>> networks via E1 links using PRI, R2 & C7/SS7 when using dialogic
> > telephony
> >
> >>> boards.
> >
> >>>
> >
> >>> e. What all features are available from the native scripting
> > language used
> >
> >>> in bayonne.
> >
> >>>
> >
> >>> f. No real description of successful implementation of bayonne in
> > telecom
> >
> >>> networks beyond "We are using bayonne!" or "We have successfully
> > implemented
> >
> >>> bayonne!"
> >
> >>>
> >
> >>> g. Is there any form of commercial support available for bayonne? Is
it
> >
> >>> possible that, if required, i can find people/companies who are
> > willing to
> >
> >>> work on getting rid of bugs or to implement new features for a fee?
> >
> >>>
> >
> >>> My company deploys high density IVR systems at telcos and currently
> > we use a
> >
> >>> proprietory platform for IVR systems. I have been trying to figure
> > out if
> >
> >>> bayonne is even a viable alternative to our current system! Our
current
> >
> >>> platform may be expensive and proprietory, but our vendor gives us
> > excellent
> >
> >>> support. Whenever we have faced any problems, our vendors have
> > helped us big
> >
> >>> time. I have never really felt confident about what would happen if
> > I face
> >
> >>> problems in a production environment. I have been following the
bayonne
> >
> >>> project for more than 1.5 years now, and I hardly see any activity.
The
> >
> >>> bayonne home pages are also not with any recent news. The
> > bayonne.sf.net
> >
> >>> page's latest news is from 27th Feb 2004 and on
> > www.gnu.org/software/bayonne
> >
> >>> the latest news item is from 2003-07-06!
> >
> >>>
> >
> >>> I really think that the bayonne project has not done much to
> > attract people
> >
> >>> who might be intrested in deploying bayonne in production
> > environments. Luca
> >
> >>> is doing a great job here, but we probably need more people doing
> > similar
> >
> >>> activity. Google tends to only turn up old articles on bayonne :-(
> >
> >>>
> >
> >>> Ambar Roy
> >
> >>> PS: Luca bayonne.sourceforge.org does not lead to the bayonne page.
> > It is
> >
> >>> bayonne.sourceforge.net or bayonne.sf.net ;-)
> >
> >>>
> >
> >>>
> >
> >>>
> >
> >>> _______________________________________________
> >
> >>> Bayonne-devel mailing list
> >
> >>> address@hidden
> >
> >>> http://lists.gnu.org/mailman/listinfo/bayonne-devel
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFCUv/pJlWtSTiTVsYRAnLHAJ4pWuNiaRZYG62U2pSYJyznKI5w/wCePVag
> pwmriR/B3quHT7lxvc1a1X8=
> =zV1Y
> -----END PGP SIGNATURE-----
>