Author: Joe 'Zonker' Brockmeier
NewsForge: Could you give us a short description of the Bayonne project?
David Sugar: Bayonne started as a platform that allows one to create and deploy applications that interact by voice and through TouchTone keypads with people over the telephone network. Bayonne includes its own scripting language for writing telephony applications, which is designed for use in very high port -capacity solutions, as well as offering services to telephony enable Perl, Python, and other common scripting languages.
NF: How did the project get the name “Bayonne”?
DS: When it was originally released in 1999 it was called ACS, which stood for Adjunct Communication Server, and even before that it was called Universal Messenger Daemon, because originally it was to be offered as a voice mail system (hence, the main service daemon was originally called umd). Unfortunately, I kept getting all these emails complaining how we were squatting on the ACS name, which also, I came to learn, stood for “Al’s Circuit Simulator.”
So in thinking of a new name, I thought of a metaphor for computer telephony as a bridge. There is of course the Brooklyn Bridge, which has many interesting connotations. There was the Golden Gate, but a lot of projects were already using that one. I had considered Tacoma, but, given its history for self-destruction, I thought it best to leave that name for possible use by a proprietary vendor in that state. But at one time I had a house on 3rd Street in Bayonne, sitting in the shadow of this bridge….
NF: Could you give us a little background on how the project started, its history, and your history with the project?
DS: There are several different histories intertwined. First, there is Open Source Telecom Corp. Back in 1998, while I was still experimenting with DBS server, I was approached by the CEO of a company that made a line of GNU/Linux-powered network appliances on funding a telephony appliance for voice messaging. At the time I already had the idea for the design of another kind of computer telephony voice application server developed as freely licensed software that could then be shaped into different applications such as that, though before then I never [had] a sponsor wanting to see it developed.
So based on the promise of this funding, and because the job of organizing a company to produce this (and other products) was too large to do alone, I got together with some people in the community I knew, including Rich Bodo, and OST was formed.
Much of the initial development work was completed when our funding source suddenly got cold feet. As this was still 1999, and there was plenty of venture funding throughout the Valley, we did not think finding another source of funding would be too difficult. This was, of course, right before the bubble burst.
So we had a business plan that involved reselling and delivering a turnkey piece of hardware that included installing and selling application support for ACS (which became Bayonne). Of course, CTI hardware was expensive then. So we would often have to somehow come up with $20K or more per sale up front to purchase hardware, and then hope the customer would pay later for the hardware, and not even at the time of delivery, but when their custom application was also complete and accepted.
Given that we had no money at all to start this business on our own, this proved to be an accounts receivables disaster. At times we carried accounts receivables on credit cards, and really by any means possible, to remain in business. Unfortunately, on the books, we were from the perspective of the IRS rather profitable, even though in fact we were all at the time rather poor.
|
GNU Bayonne maintainer David Sugar |
If we had initial funding, this could have worked, since there would have been resources available for funding initial purchases, especially given the large returns after delivery and acceptance, but right after we started selling, of course, the bubble burst, and suddenly there was no funding to be had at all. We eventually reached a point where we could not afford to raise money to purchase hardware for any new customers, and we accumulated a rather large IRS debt. So OST was folded last year.
Rich currently runs Telephonyware, which is focused on traditional resale of telephony hardware generally without customization, and he seems to mostly focus on smaller commodity items (such as VoIP phones) that are easy to inventory and resell to someone else if a customer changes their mind before paying, rather than custom CTI servers with $20K worth of T1 cards.
The design for Bayonne was actually drawn up in the early ’90s — in fact, maybe even before even the DBS server was released. Unlike other industries, telephony was already principally a services-oriented business, filled with thousands of VARs and integrators, all of whom were desperately trying to make one-size-fits-all proprietary solutions actually fit their customer’s real needs. It was in this segment, rather than OEMs, where much of the money and dynamics existed in telecommunications. Hence, it seemed the ideal environment to introduce free software and the commercial idea of software as service.
When I laid down the Bayonne architecture as code, I choose to do so in C++, because I thought it would be easier to maintain. I believe this assertion was proven correct, at least for me. At the time, we were one of the very few large FOSS projects to use C++ rather than C.
At the time I also choose to separate and maintain several additional libraries. I thought that while very few people would be interested in Bayonne, a lot of people may be interested in a C++ threading and socket framework (GNU Common C++), an RTP stack (ccRTP), etc. The idea then was that while I thought only a few people might participate in Bayonne, more would do so in the parts if they were done separately, and as a result, the quality of code for those essential parts would rapidly improve. Given that these libraries were core services for building something like Bayonne, this would mean the lowest level and most tricky things would get much wider testing and would become very stable. In fact, over the years, several hundred people have in one way or another touched GNU Common C++, and so this idea also proved valid.
Of course with the difficulties with OST in 2003 and 2004, I spent less time maintaining Bayonne. This was especially true when I was hospitalized during part of 2004. After that, I was kept busy in other areas, and unfortunately one of the people who I thought would introduce future releases during that time did not.
By May of this year, I found myself suddenly with a considerable amount of time and availability, and a number of people who had been principally involved in the project from its earlier days came to me with ideas of what we should do. In the end we choose the more radical approach of rewriting the entire server, and radically simplifying the code so that it would be easier to maintain in the future. To this I added the idea of a core library which other projects could also use to access Bayonne drivers and core call processing.
While a very large rewrite, that was actually done very rapidly in June, and the core features and architecture proved very stable for Bayonne 2. If we introduce a 1.0 release at the end of the month, I may also re-open Tycho Softworks, both to commercially support it and the current production release (Bayonne “1” 1.2.15) which is used worldwide, although I have no interest in reselling hardware in any form.
NF: According to the site, I see that Bayonne 2 is a testing release — how close is this release to being “stable,” and what’s holding it back from being considered stable? Features, stability, or just in need of additional testing?
DS: Some parts of Bayonne 2 are very stable, including the core architecture, libexec execution module, and basic IVR scripting language features. There is some thought of making a 1.0 release of Bayonne 2 around these core features, while other parts of Bayonne 2 continue to evolve further.
In the past, like some projects, we have had stable and experimental features mixed together at CVS head, and then we hope a stable release would eventually emerge out of the chaos. Sometimes this does happen as a project matures, especially if it has a clear and limited functional domain, and you reach a point where that functional domain has been reached, so no new experimental features are being added and the existing core features then get time to be completed. This eventually happened with our supporting library packages.
At the moment, I like the idea of taking a current development tree, paring it down a bit to get the truly stable feature set, and making a baseline release which is then separately maintained in a tightly controlled way. If this methodology works successfully, I expect to do similar with future Bayonne 2 releases such as for 2.0.
NF: Could you tell us about the GNU Alexandria project, and how it utilizes Bayonne?
DS: GNU Alexandria started from the idea of having a Bayonne server parse an XML dialect known as “Daisy.” Daisy is a new standard designed for publication of electronic talking books, and as a medium that can be used to present documents that can then be electronically read by the blind. I think it is most closely related to XML SIMPL for embedding multimedia content in a non-proprietary XML document, which, according to Microsoft, does not exist.
A version and proof of concept was developed by a federal contractor with some encouragement from the American Foundation for the Blind, and field-tested with the US Medicare service to create a telephone service which can read and navigate a Medicare program document with a TouchTone phone several years back. This used Bayonne to drive a Python application which then parsed Daisy XML.
Bayonne 2 offers a much better way of handling this kind of application because we can decapitate the server and use just use libbayonne with an XML parser directly. This means a new XML server can then be added on top of libbayonne which can then directly parse Daisy, rather than having to string together several loosely coupled components written in several different languages to do this. Hence, what I want to do with GNU Alexandria is offer a server that sits on top of libbayonne to parse Daisy directly, and some other standalone tools for manipulating Daisy content.
NF: Aside from telephony, what types of services is Bayonne suitable for?
DS: Video and video voice mail is an idea that had been suggested to me by Aymeric (who maintains OSIP). I was considering RTSP, which would allow one to create an Internet switchboard that could receive calls and rebroadcast them as streaming content. Some applications in Internet radio or even IPTV could benefit from that.
NF: Is there much emphasis on supporting standard PC hardware like sound cards with Bayonne, in addition to telephony hardware?
Bayonne can be used with sound cards on local PCs for testing and developing telephony applications without [users] needing to purchase and set up computer telephony hardware. Bayonne 2 also offers SIP and H.323, so that it can be used in VoIP telephone networks, and one can use things like GnomeMeeting or Linphone to test and develop applications as well.
NF: What features are on the table for future releases of Bayonne?
DS: Switching support, event queuing, and audio peering have been rewritten in Bayonne 2, and one extension of this was the creation of services bindings so that one can use a Bayonne server as a switch and route calls directly, particularly to interconnect PSTN to VoIP as a gateway, as well as serving voice applications. Much of this work is already initiated and in active development in Bayonne 2, though if we extract a stable 1.0 release in the immediate future, the extracted branch will be without those additional services.
Another important area of development is something I like to call the Bayonne Application Library. This is meant to offer scripting macros which invoke features of other existing FOSS applications easily. For example, what if you need to create an application that integrates with SQL-Ledger, and you need to allow a telephone caller to look up an order number? Or to post a voice message as a Web form email document for PHP groupware? The ability to get to that type of functionality would be the kind of things one would expect to find in the Bayonne Application Library.
Finally, I am interested in various forms of XML services using libbayonne, like in GNU Alexandria. Another possibility could be to combine libbayonne with OpenVXI to offer a Voice XML server.
Category:
- Enterprise Applications
