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:[EMAIL PROTECTED]> > > *To:* David Sugar <mailto:[EMAIL PROTECTED]> ; Ambar Roy > > <mailto:[EMAIL PROTECTED]> > > *Cc:* [email protected] <mailto:[email protected]> > > *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: > > [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] > > On Behalf Of David Sugar > > Sent: April 5, 2005 9:40 AM > > To: Ambar Roy > > Cc: [email protected] > > 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 > > > >>> [email protected] > > > >>> 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----- > _______________________________________________ Bayonne-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bayonne-devel
