=============================================
See http://www.gnu.org/software/bayonne for general information.
1. What is this?
2. GNU Common C++ updates
3. A GNU ccAudio release
4. GNU ccScript updated
5. GNU Bayonne and PRI spans
6. Apennine reaches new heights
7. Packaging help
8. GNUCOMM User Agent
9. What is next?
What is this?
~~~~~~~~~~~~~
After some thought, I have decided to have a more structured document to publish as important things are going on in GNU Bayonne. I decided against a weekly format like many projects have chosen to do simply because I did not wish to have to find things every week, or to highlight something that would otherwise be trivia in a slow week.
As it happens, there have been weekly updates for the last few weeks because of many different things going on simultaneously in GNU Bayonne and related packages. For the most part, this particular what's new will happen to cover what is more recent and relevant since last weeks update in this area.
As it happens I will be away next week in the Netherlands attending Linux Kongress and speaking about GNU Bayonne. We may try to do some further work while there, but it is unlikely there will be much new before December. I will also be speaking at next year's GNU/LinuxWorld being held in NYC, about DotGNU.
GNU Common C++ updates
~~~~~~~~~~~~~~~~~~~~~~
After a couple of weeks, we found it was necessary to release GNU Common C++ 1.9.1. This release attempts to fix many of the new problems that were created by the great leap forward from 1.6.x to 1.9.0. This release fixes and extends native win32 builds by making sure all major classes are properly exported. Support forward for gcc 3.0 and backward for some older gcc compilers have also been fixed. I believe there is still a problem with Solaris targets, although that is being worked on.
In addition to these changes, we have tried to introduce support in the win32 native build of GNU Common C++ for the native build of GNOME libxml that is provided by Igor Zlatkovic. We still have some problems with using these, so this will have to wait for the next release. Ideally, we do want xml parsing in all platforms for the GNU SEE daemon and for the GNUCOMM user agent, but more about that is covered in GNU ccAudio...
A GNU ccAudio release
~~~~~~~~~~~~~~~~~~~~~
In addition to GNU Common C++, we had a new release of GNU ccAudio. With this new release we have now made GNU ccAudio depend on GNU Common C++. This solved several problems, including having to use duplicate tests for things like namespace support between the two, and being able to use the GNU Common C++ macros for constructing portable compilable classes as shared libraries.
Another reason for this change was to be able to use GNU Common C++'s dynamic class loader to support distribution of freely licensed software codec's as part of future GNU ccAudio releases. Software codecs are important for many current and future projects in GNUCOMM, including GNU Bayonne, the phone client project, and the IP gateway proxy.
Finally, we expect to now be able support more multimedia features in GNU ccAudio. This can include simple things like a thread operation to play an audio prompt, or more complex audio operations. GNU ccAudio will also need loadable module support from GNU Common C++ to do soundcard interfaces, so that one can seamlessly plugin oss based audio, esd, arts, or any other audio interface at runtime. In particular, supporting full duplex audio in some form is necessary for the GNUCOMM user agent.
There are many areas of multimedia operations and signal processing that we would like to take GNU ccAudio forward to in the future. Being able to perform FFT's on sample buffers and perform host based tone detection is one area of interest. Another is in audio mixing and equalizing. I would also like to see if we can create packet frame mpeg decoding to issue frames of mpeg audio out to sound devices such as telephony hardware (GNU Bayonne), sound cards, or IP channels (GNU ccRTP).
GNU ccScript updated
~~~~~~~~~~~~~~~~~~~~
Along with other core GNUCOMM libraries, there is a new release of GNU ccScript available. In this new release, we simply have extended the use of runtime loadable ccScript extension modules by moving some core language elements into external modules. In particular we have
externalized date and time handling.
GNU Bayonne and PRI spans
~~~~~~~~~~~~~~~~~~~~~~~~~
Naturally, there is a new release of GNU Bayonne, 0.7.3, now out this week. I had some plans to provide standardized applications as part of GNU Bayonne for voice messaging, debit calling, and acd call queuing. In fact, none of these were complete enough this week to be part of this release.
Rather we chose to provide a new release of GNU Bayonne at this time so that people can start testing and deploying PRI based applications. We have had a great deal of success in completing ISDN support on PRI spans for GNU Bayonne using the Dialogic hardware. This was largely due to both the help of Mark Lipscombe, and the facilities of OSDL. We can now demonstrate and deploy PRI hosted applications, both for inbound and outbound calls, and so this seemed a good opportune moment to create a new release.
At the same time, we have worked at improving and standardizing call progress analysis in GNU Bayonne. This has been done across all existing drivers, and should further expand the functional capabilities of GNU Bayonne for outbound dialing applications.
Apennine reaches new heights
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Some may recall I created Apennine to provide a generic XMLRPC server that can sit on top of all of GNUCOMM, including GNU Bayonne. By using dso modules, one can add functionality for those GNUCOMM services running on each machine.
Originally Apennine was looked upon simply as a way to bridge phpGW to GNU Bayonne. For example, one might be able to use Apennine and some changes in phpGW to get the phpGW address book to use GNU Bayonne to dial out phone numbers when you click on their entries. Another example might be unified messaging that interconnects phpGW with GNU Bayonne.
Since XMLRPC is carried on http, to a very real extent Apennine is also a web server. I have thought of broadening it's mission, so that in addition to attaching dso modules for xmlrpc, one could map web space to loaded modules. There are places where presenting GNUCOMM services thru a web interface may be very useful. For example, being able to browse the "status" of active GNU Bayonne connections. I think if we add web pages to Apennine for things like this, they should be exported as .xhtml, so that they may easily be browsed and parsed by other automated systems.
Packaging Help
~~~~~~~~~~~~~~
It has been awhile since we had GNU Bayonne and associated applications distributed in pre-packaged binaries. I would like to re-introduce this, and in particular introduce .deb's, as well as actively maintain the FreeBSD ports entries for these packages.
As it happens, a new Debian developer has come to me offering to package Bayonne. I would like to see if we can get more volunteers to maintain other pre-packaged formats. I do not have time to do this on a regular basis, and having volunteers do these would be very helpful.
GNUCOMM User Agent
~~~~~~~~~~~~~~~~~~
Plans are moving forward to introduce a GNUCOMM "user agent", or softphone. This would use GNU Common C++ as the base for plugin support, GNU ccRTP for the realtime audio transport, oSIP for call signaling and text messaging, the FOX GUI for the user interface, and GNU ccAudio for audio processing.
The GNUCOMM user agent will be both an instant messaging client and a VoIP telephone for use in the rest of GNUCOMM. The use of plugins will allow the GNUCOMM user agent to provide plugin services and visual interface extensions for role specific applications. Imagine, for example, a GNUCOMM user agent for an ACD agent on a IP telephone network, where the user agent provides thru a plugin information on call queue status and common ACD phone controls, in addition to acting as a standard client.
Ideally we would like to make the GNUCOMM user agent the centerpiece for all inter-user communications on free platforms, and to do so in a fully integrated and unified fashion between voice and messaging, as well as offering support for connecting to the public telephone network thru gateways, point of presence detection, and user directory services, perhaps all done thru SIP.
This at least is the outline of what this package will encompess. We are looking for some additional volunteers who would be interested in helping with getting the user agent project going forward. In particular, there are some areas in GNU ccAudio that needs to be completed before much further work can be done on the user agent proper.
What is Next?
~~~~~~~~~~~~~
In the short term, I want to complete work on the standard application set that will comprise GNU Bayonne in the future. One should be able to take GNU Bayonne out of the box and create or modify standard applications without having to build new ones from scratch.
We also have been given a Brooktrout card to play with, and I hope to be able to introduce Brooktrout support in GNU Bayonne soon. We are always looking to expand the telephony hardware that we can support, and this often requires assistance or hardware to test with from different vendors.
In OSDL, now that basic digital operations are complete, we hope to look at supporting Intel/Dialogic audio conferencing (mixer) cards. There is already some support and architecture in place for making GNU Bayonne into an audio conference bridge using Pika hardware. We want to generalize this to other drivers where possible.
In the CAPI driver, a "soft" or non-TDM version of "join" was created. I would like to introduce this into other non-TDM capable telephony drivers. Some "soft" audio conference mixing might also be possible.
The current Intel/Dialogic ISDN support is based on the existing digital runtime. I would like to see a new pure GlobalCall implimentation of the GNU Bayonne dialogic driver get created.
Fax support has been overlooked, and I think we should provide it as we can do interesting things like user guided faxback systems with GNU Bayonne. Completing RTP and OH323 trunking is also a priority item to have GNU Bayonne act as a softswitch application server.
There are many other areas being worked on. We always can use more
help...
David"