dcsimg
Linux Today: Linux News On Internet Time.





This year in GNU Bayonne (December 31, 2001)

Jan 02, 2002, 14:45 (0 Talkback[s])

[ Thanks to David Sugar for this link. ]

This year in GNU Bayonne (December 31, 2001)
============================================
See http://www.gnu.org/software/bayonne for general information.


1. What happened this past year
2. GNU Bayonne 1.0 Introduction
3. What will Bayonne 1.0 have?
4. What has been dropped in 1.0?
5. What are Olorin and Babylon?
6. GNU Bayonne events in 2002
7. What is next

What happened this past year
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Actually quite a bit happened this past year. We went thru two major releases and with the help of OSDL and others we were finally able to deliver high density digital telephony services thru GNU Bayonne using Dialogic hardware.

To make GNU Bayonne more widely used, we had help from Kai Germaschewski who did some excellent work getting CAPI 2.0 support to work for European ISDN users.

One of the big changes in GNU Bayonne this year had been development of XML services. These are being carried forward to their logical conclusion in the 1.0 release, but we are getting ahead here.

At the start of the year we received the "Best new Enterprise Application" award from the Singapore Linux Conference. We have been trying to live up to this award all year long!

This year I also had been serving as the communities elected representative to the International Softswitch Consortium. This actually involved a bit of travel and resulted in some interesting contacts. It also perhaps most profoundly effected my decision to finally introduce as free software a softswitch application server, Olorin, to compliment the GNUCOMM softswitch effort.

Perhaps one of the most interesting and useful things to happen for GNU Bayonne has been it's acceptance as a project in OSDL. This has provided us with access to enterprise and carrier level hardware to develop and test GNU Bayonne. This facility has been used somewhat minimally so far this year, especially since soon after it's availability late this year I had marched off to work on Bayonne 1.0, but I expect to see much greater use of it occur during the next year.

The most important development however has been the increasing commercial acceptance of GNU Bayonne. This perhaps is represented in part by it's acceptance in OSDL, but also in the use of GNU Bayonne in e-government by the State of Maine and similar commercial venues, and by the demonstration of a Bayonne based unified messaging product at Linux World in San Francisco.

However, all these things have been overshadowed by events in December, leading to the introduction of GNU Bayonne 1.0, and the first acceptance of Bayonne by a commercial carrier to deliver various dialtone services starting next year.

GNU Bayonne 1.0 Introduction
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
During early 2002 we will be introducing the 1.0 release of GNU Bayonne. This release and the ones that will be immediately prior have been drawn from an entirely new code base that was created starting in December. This new code base is used to generate Bayonne, Olorin, and Babylon, from a single source package.

The plan for release of GNU Bayonne 1.0 will start with the transfer of the new code base to public cvs on Savannah. This will be placed under the "BayonneNG" module name in the Bayonne cvs repository on Savannah, and should be in place at the time this document is distributed, or on January 1st.

This new code base is drawn from entirely newly written code. The entire server, including class hierarchy, has been reviewed and selectively re-implemented from scratch over the month of December. Those features that will be part of a final 1.0 release have been kept, and some features have been selectively abandoned.

The initial builds of Bayonne 1.0 will likely be labeled 0.9, and the first 0.9 release will be distributed around the end of January. In fact, it will likely take all of January to bring the new server code to the point where it is usable in a release. This will be followed by a final set of 0.99 releases, and the full 1.0 release of Bayonne, perhaps around May, where I hope I may be able to formally introduce it as part of a GNU Telephony WiP at SANE in the Netherlands.

The 0.9 release will immediately introduce the new Olorin and Babylon servers which are also to become a standard part of Bayonne and the 1.0 package release. These servers are still in somewhat preliminary form, and may not mature until mid-year. Perhaps the "2.0" release of Bayonne will include what one might consider to be the actual "1.0" release of Olorin and Babylon, depending on how progress on testing and documentation occur in these two additional servers over the new year.

What will Bayonne 1.0 have?
~~~~~~~~~~~~~~~~~~~~~~~~~~~
To better support carrier class services and hardware, Bayonne has been rewritten to support hot swap (cPCI) services. This allows Bayonne to take ports or groups of spans selectively out of service into a standby mode and return resources to the OS.

Perhaps by far the most important part of Bayonne 1.0 is what will actually be introduced at "GNU/"LinuxWorld in NYC. What I will say of it at this time is that it is an entirely new framework for building and supporting all forms of telephony media devices and that it will probably change the way all telephony applications are written in the future for free operating systems, not just for Bayonne. In fact, the introduction of this framework was one of the principle reasons for a complete rewrite of Bayonne to be undertaken at this time.

For testing purposes, it is now possible to execute Bayonne without any special telephony hardware. A functional "dummy" device exists which can simulate hardware behavior and allow applications to be tested and executed under keyboard control. If the machine has an OSS based sound card, it will be used to perform audio processing operations on the local PC, and hence allow one to simulate behavior of Bayonne applications and demonstrate services without any telephony hardware.

Integration of Bayonne with PreViking based Infotel services is also a major change for the 1.0 release. The Viking Infotel server will be used provide standard database access in much the way BayonneDB had been intended for things like call detail records, for balance lookup on debit transactions, etc.

System monitoring thru a tcp port connection will also become a standard part of Bayonne 1.0. This will allow both command driven "shell" access to the Bayonne server's internal operation states, and the ability to create a front-end gui to monitor running servers. Between system monitoring and the ability to pre-test servers, it should be possible to more effectively deploy and debug both applications and running servers to the level needed for a commercial network operations center.

The use of XML in Bayonne has been extended for 1.0. Bayonne, Olorin, and Babylon will now parse an shared XML based "configuration document". This document can either reside on the local file system as a /etc file, or it can be fetched from an internal web server during startup. This should allow one to globally configure a group of Bayonne, Olorin, and/or Babylon servers from a central server. Remote fetching of scripts and voice libraries during startup is also being worked on.

To better support creation of dedicated commodity and embedded telephony applications, such as turnkey voice mail systems, it will soon become possible to compile and build Bayonne servers in a "light" mode which uses no XML support. This will be done by constructing a GNU Common C++ library without XML support. I am also looking at generating a further function reduced GNU Common C++ build that will reduce the footprint of Bayonne even further when so desired.

Another change is support for user scripting. User scripting enabled anyone with a login id on a box running a Bayonne, Olorin, or Babylon server to create and manage their own telephony application service with their own prompt library once they are added to the bayonne group by the system admin and by assigning number routing to such user services thru Infotel, such as by DNIS, for example. This is conceptually similar to how users might create personal web sites on an Apache server by placing a public_html folder in their home. This permits one to host telephony "services" for outside users and easily create a telephony ASP even without using XML.

Where in the past Bayonne has been distributed without prebuilt sample applications, this will be changed starting with the 1.0 release. Currently there are several different groups working on Bayonne applications for both the current and the 1.0 release series, both in the US and abroad. Some of these we expect to demonstrate at GNU/LinuxWorld in NYC next month.

Perhaps the greatest single change in the whole project is that the entire source tree has been simplified. It is now possible to intelligibly find where sources for various parts of Bayonne are without having to go thru several directory levels.

FAX support is an interesting question that currently is being re-visited in Bayonne 1.0. We have not supported FAX operations in the past except in conjunction with Hylafax, but we expect to do so directly sometime in the future. I am not sure if FAX support will make it in time for 1.0, however. It may have to wait for "1.1".

Finally, GNU Bayonne is absorbing functionality from the PreViking telephony server. PreViking, along with Infotel, and some other soon to be announced things, are GPL licensed telephony related projects that are sponsored by Telesave in the UK. Bayonne 1.0 will directly offer functional services constructed thru scripting that match those currently provided by PreViking, including debit calling and answering services, and will also offer some additional services related to building of ACD systems, unified messaging, and hosting of voice commerce.

What has been dropped in 1.0?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I have chosen not to implement the Pika driver for the 1.0 release of Bayonne. This is due to the fact that the card and software are not actively maintained for GNU/Linux any longer.

There have also been a lot of odd ways of integrating Bayonne with web services, including cgi wrappers, and even ssh stuff. All of this cruft has been removed. XMLRPC as provided thru the GNUCOMM Apennine server will become the standard way to interact with a running GNUCOMM services, whether from the web or other applications.

I am sure there are enough minor differences to confuse some. In fact, one of the biggest problems is that the current project documentation is already well obsolete, even before the rewrite. Hence, the current documentation, in effect, is being dropped until it can be rewritten.

What are Olorin and Babylon?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
One of the changes not so visible has been how we restructured the primary class hierarchy of Bayonne in the 1.0 series. The most striking change is that, like GNU ccScript, the entire processing state engine of GNU Bayonne is now represented thru a class extensible state machine that is now found in the primary server rather than having to be coded in each and every driver, as was the case with the past.

This change has made it possible to directly derive alternate servers out of the common Bayonne source tree by changing some middle classes. The result is that we now can build at least three servers out of a common source package; Bayonne, Olorin, and Babylon. Both Olorin and Babylon each share many common attributes with Bayonne, but have specific sets of functionality that is branched from the main Bayonne tree. Since they share many of the same server base classes, they can also use the same plugins.

What Olorin does is provide a Bayonne-like server for next generation telephone networks. It essentially provides a script driven application server that resides on top of a RTP media session stack. To manage session control, a SIP stack is used in Olorin. Each RTP session has an instance of an Olorin interpreter just as each instance of a Bayonne telephony port has a Bayonne interpreter. The dialects are similar, though not identical. For example, Olorin provides access to "sdes" RTP source info, where such a concept does not exist in Bayonne. Olorin requires no hardware and operates purely with VoIP telephone networks. Olorin directly provides both media and application scripting services in one server. With Bayonne's support for XML parsing thru transcoding, Olorin will act as a XML based softswitch application server.

Babylon is a media-free server that is used to provide pure application scripting logic for traditional PBX systems. Babylon also differs from Bayonne in that it provides extra support to implement the TOSI spec for third party call control and provides other provisions for standard switch integration protocols. Babylon requires drivers that are aware of native and sometimes proprietary protocols that are used by PBX systems. These are often carried on serial links, and Babylon also can provide a means of taking these native protocols and making them network accessible as well as script driven. Babylon shares the state model of Bayonne and Olorin, where switching equipment often has it's own call control model, sometimes derived from CSTA. This makes Babylon drivers far more complex than Bayonne ones.

Collectively, Bayonne, Olorin, and Babylon provide application services in GNUCOMM for both current and next generation telephone systems. They also are to be the foundation of telephony services in GNU Enterprise and packages that reflect GNU Enterprise modules will also be created as part of GNU Bayonne, such as GNU Bayonne Customer Relations Management, which will do telephony operations related to that portion of GNUe.

GNU Bayonne Events in 2002
~~~~~~~~~~~~~~~~~~~~~~~~~~
I have been kindly asked by Greg Herlein to run this year's Telephony BOF at next year's GNU/LinuxWorld in NYC on Thursday night. I also happen to be speaking at GNU/LW at the DotGNU panel on Wednesday as I happen to chair that project, and will generally be around the GNUCOMM booth in the .org pavilion where I and others will be demonstrating GNU Bayonne old and new, and the "other" thing that should be introduced then.

In May I currently hope to return to the Netherlands to give a BoF and/or WiP on GNU Telephony and GNUCOMM as a whole at next year's SANE conference, as that should be the right time to distribute the final Bayonne 1.0 release.

In July I will try to be back in France to speak at next year's LSM event, to be held in the second or third week of July at the University of Bordeaux. I expect it is likely I will be speaking both about GNU Bayonne and DotGNU, as we will have a gathering of the DotGNU steering committee during the LSM.

What is next
~~~~~~~~~~~~
Now that GNU Bayonne is getting close to 1.0, we can start looking to where we wish to take telephony application services in the future with free software. In this sense, three projects will become ever more intermingled with the future of GNU Bayonne; the GNU project itself as a whole, phpGroupWare and by extension DotGNU, and GNU Enterprise.

The role of GNU Enterprise and GNU Bayonne had been addressed before, when Bayonne replaced the EWOK component of GNU Enterprise. This role will become more important as we focus more on delivering applications with GNU Bayonne. We do intend to deliver applications that are integral with those of GNU Enterprise where GNU Enterprise requires telephony services, as well as providing general enterprise level telephony application services.

phpGroupWare represents how we wish to make GNU Bayonne usable as part of everyday life for the enterprise worker. By enabling XMLRPC support thru Apennine and it's future decedent, we expend to enable things like having the phpGroupWare address book dial out to people using Bayonne, Babylon, or Olorin, depending on the user's enterprise environment. Another big area left to be explored is delivery of unified web based messaging and GNU Bayonne voice mail thru phpGroupWare.

Finally, GNU Bayonne is, of course, part of the GNU project. This means we should work better as a natural part of GNU, and look at ways that other parts of GNU can work with GNU Bayonne. Supporting guile for TGI applications is one way we can do this. Supporting pnet as part of GNU Bayonne is another way, and we do expect to provide a pnetlib framework for providing telephony enabled web services as an effort related to GNU Bayonne.

Our mission in GNUCOMM as a whole is to provide and standardize telephony services for the individual user, for the enterprise, and for commercial carriers, under free software. For this reason, GNU Bayonne will continue to evolve as the standard telephony application services platform of the GNU project.

Any questions or comments can be addressed to David Sugar

Related Stories: