Re: [Bayonne-devel] web article about Bayonne

[David Sugar]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

There is extensive documentation and faq on installation and on the
scripting language.  There is still lacking a good admin guide.  Some of
these things can be found in the doc directory, and if you make the
docs, and have the right set of packages installed, it will also build
complete pdf's of the standard Bayonne manuals for you.

Ambar Roy wrote:
> 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-----
>>
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCU+k1JlWtSTiTVsYRApT9AJ9ZFQ66O5FDNKHNQdXUZVUK2dcLAwCfcKg6
QZm3naS/jiZNoGN3Ni2GXLI=
=aA/+
-----END PGP SIGNATURE-----

dyfet.vcf
Description: Vcard