GNU Bayonne Is for Telephony
As noted earlier, we achieved all these goals some two years ago with the first of these telephony application servers, which as previously stated, which was called Adjunct Communication Server or ACS, for short. Unfortunately, ACS suffered from a name problem, and I received many letters from different people pointing out that ACS was used by several other projects, including Al's Circuit Simulator. Clearly this was a problem.
At the same time, the ACS architecture was showing its limitations. First, it was based on the idea of building a server directly bound to the telephony card, much the way XFree86 3 bound the X server to a given family of video hardware. This meant separate servers had to be compiled for each card family, and a lot of code was being duplicated needlessly.
I chose to rewrite the entire core server from scratch, and this was completed over a period of a few weeks. The first thing I did was create a concept for supporting plugins, using a somewhat different idea from how most people had done plugins in the past.
Typically, a plugin would be a small object file dynamically loaded with a known symbol name or structure that could be found easily once the loaded file was examined. Hence, one can use dlopen to open the plugin and dlsym to find a known symbol, thereby calling functions within the plugin.
I came up with a different method: I made the new server export its own dynamic symbols. The server then had a bunch of base classes with constructors that would initialize a registration structure. The plugins were written instead as C++ derived classes, where the base class was defined in the server and had static objects for these derived classes. When the plugin was loaded with dlopen, the constructors of these static objects would be invoked automatically, and the base class references to the server image resolved automatically. The base class held inside the server image would be invoked from the constructor, and it would register the plugin object. Hence, a single dlopen would both load the plugin and perform all initialization as a single operation.
Furthermore, things that were part of ACS got spun off as separate packages. This is when GNU ccScript and GNU ccAudio became separate class libraries, as these represented the already useful scripting engine and audio processing functionality found in ACS. In particular, we were looking at using the scripting language in other servers that would be part of GNUCOMM.
GNU ccAudio has proven to be a useful general-purpose audio processing library. It can be used to pregenerate single- and dual-frequency tones that can be played later from memory, and it can assemble audio from multiple input files into packed, fixed-sized frames with silence filling at the end, as is commonly needed for feeding DSPs (digital signal processing). This feature makes it a bit unique because other audio processing libraries typically do not concern themselves with these issues. Ideally, I would like to extend GNU ccAudio into a full, general-purpose audio processing framework that can also be used to provide host-based DSP-like processing.
So we had a new server, only it lacked a name. Since we wanted something distinct and unlikely to be used by someone else, we decided not to use yet another acronym. Instead, since the server was essentially a bridge between the computer and telephony world, it seemed natural to choose a bridge for a metaphor. But what bridge?
There of course is the Brooklyn Bridge. But overused and having bad connotations, it seemed a bad choice. Similarly, Golden Gate is extremely overused and, in any case, associated with IBM's Java initiative. Tacoma Narrows was a possibility, but considering it was famous for self-destructing, we thought we would leave that one alone, perhaps for a proprietary vendor in Washington.
There is a bridge not far from where we are in New Jersey: the Bayonne Bridge. Virtually nobody has heard of it, and in any case, the name is little-used.
Summer 2002 marks the introduction of the 1.0 release of GNU Bayonne. At present, GNU Bayonne is part of not only the GNU Project, but it has been packaged and distributed as a standard part of several GNU/Linux distributions, including GNU/Debian and Mandrake. In that we wish to make telephony application services universally available to free software developers, this is a positive development.
GNU Bayonne is widely used already in every part of the world. Users range from commercial carriers in Russia to state and federal government agencies in the US, and they include many enterprises that are looking for either specialized telephony-enabled web services or a platform for enterprise applications such as voice messaging.
GNU Bayonne does not exist alone but is part of a larger metaproject: GNUCOMM. The goal of GNUCOMM is to provide telephony services for both current and next-generation telephone networks using freely licensed software. These services can be defined as 1) services that interact with desktop users, such as address books that can dial phones and soft phone applications; 2) services for telephone switching, such as the IPSwitch GNU Softswitch Project and GNU oSIP proxy server; 3) services for gateways between current and next generation telephone networks, such as troll, and proxies between firewalled telephone networks such as Ogre; 4) real-time database transaction systems, such as preViking Infotel and BayonneDB; and 5) voice application services, such as those delivered through GNU Bayonne.
Even before GNU Bayonne 1.0 had been finalized, work started in late 2001 on a successor to GNU Bayonne. This successor attempts to simplify many of the architectural choices that were made early on in the project, with the hope of making it easier to adapt and integrate GNU Bayonne in new ways. The choice of design and much of the initial planning occurred during a two-day period late in 2001, while I was in London meeting with the people who developed the preViking telephony server. Some of these changes involved bringing the preViking Project directly into GNU Bayonne development.
One of the biggest challenges in the current GNU Bayonne server is creating telephony card plugins. These often involve the implementation of a complete state machine for each and every driver, and often the code is duplicated. GNU Bayonne 2 solves this by pushing the state machine into the core server and making it fully abstract through C++ class extension. This allows drivers to be simplified, but it also enables us to build multiple servers from a single code base.
Another key difference in GNU Bayonne 2 is much more direct support for carrier-grade Linux solutions. In particular, unlike its predecessor, this new server can take ports in and out of service on a live server, allowing for cards to be hot-plugged or hot-swapped. On a carrier-grade platform, the kernel will provide notification of changeover events, and application services can listen for and respond to these events. GNU Bayonne 2 is designed to support this concept of notification for management of resources it is controlling.
Finally, GNU Bayonne 2 is designed from the ground up to take advantage of XML in various ways. It uses a custom XML dialect as a configuration language. It also acts as a web service with both the ability to request XML content that describes the running state of GNU Bayonne services and the ability to support XMLRPC. This fits into our vision for making telephony servers integrate with web services, representing part of how we envision the project going forward.
David Sugar has been involved in developing free software over the last 20 years and is the principal author of a number of packages in the GNU Project, including GNU Bayonne. David Sugar is a founder of Open Source Telecom and chairs the DotGNU steering committee.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Interview with Patrick Volkerding
- Google's SwiftShader Released
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Tech Tip: Really Simple HTTP Server with Python
- SuperTuxKart 0.9.2 Released
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Returning Values from Bash Functions
- Managing Linux Using Puppet
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide