What’s new in GNU Bayonne (December 5th)

15

Author: JT Smith

David Sugar tells us about what’s new in GNU Bayonne (December 5, 2001),
See http://www.gnu.org/software/bayonne for general information.

1. What is new?
2. Bayonne ISDN and CAPI support
3. What I am doing in GNUCOMM
4. PV Info Server and BayonneDB
5. Outline of Bayonne changes
6. “GNU/”LinuxWorld NYC
7. Where help is needed

What is new?
~~~~~~~~~~~~
With all that has been going on, it seemed a good time to distribute
updates for all major packages that are part of GNUCOMM. This includes
GNU Common C++, GNU ccRTP, GNU ccAudio, GNU ccScript, and GNU Bayonne.
This massive release includes many changes I worked on while in the
Netherlands and London last week, as well as major changes contributed by
others.

In GNU ccRTP, Frederico contributed a number of important fixes for
multicast support and other problems which made a new release necessary.
This new release also includes what has been worked on by me for the GNU
user agent so far.

In GNU Common C++, we had a number of bug fixes, patches, etc, that came
in thru the last couple of weeks from various sources. Freddy continues
to improve the win32 builds. In addition, I have added some common server
design patterns to the package.

I found a number of small and interesting bug fixes to do in GNU ccScript.
In GNU ccAudio, a change in GNU Common C++ made it necessary to re-release
this as well.

One might gather I had been a bit busy while I was away in Europe last
week. I also have outlined plans for Bayonne development thru early next
year, including some large scale changes I hope we will be able to
complete and demonstrate by the time of GNU/LinuxWorld NYC at the end of
January. Some of these recent core library changes were undertaken to
make that goal easier to accomplish.

Bayonne ISDN and CAPI support
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Among other things I had a chance to work with Zaheer in testing the
Bayonne CAPI support. We found a few problems in the current code base,
and have cleaned them up to the point where CAPI is again functional in
0.7.4. This was the first time of course I had been able to see the CAPI
driver run at all, or to do any live testing on the original submitted
code.

Meanwhile, we have added more complete call progress analysis support to
the Dialogic ISDN driver. The PRI driver can be tested in places like
OSDL for those wishing to work on improving it further. We may soon have
other locations available to us again for testing PRI support on live
spans with dialable numbers. We also have excellent development and
testing facilities inside OSDL today, although they lack live circuits.
If anyone has a location they would like to contribute for live Bayonne
testing, please contact me.

What I am doing in GNUCOMM
~~~~~~~~~~~~~~~~~~~~~~~~~~
There are things I am looking to do to help move GNUCOMM as a whole
forward into next generation telephone networks. What I envision is a
seamless environment where we will have a GNU user agent with plugins used
along with SIP phones for station side telephony services. These new
services will be driven thru the IPSwitch project and a new Bayonne
derived softswitch application server, Olorin, as well as a gateway
server.

Within this scheme we hope to fully address next generation telephone
server needs. We would like soon to be able to test some GNUCOMM
components with existing softswitch and gateway software and products.
In particular, I would like to test what will become Olorin with a Sonus
switch or similar equipment sometime early next year if this can be
arranged for.

Rich Bodo is of course responsible for carrying GNUCOMM forward as a
whole. I am articulating how this will happen within those projects I am
carrying forward under GNUCOMM for next year. While softswitch and next
generation telephone network support is certainly important for GNUCOMM,
this is not actually the area I personally am primarily focused on for
early next year. Rather, I am looking at improving support for carrier
based and commercial deployment of GNU Bayonne for existing telephone
networks. We do expect to significantly improve commercial deployability
of GNUCOMM services for existing telephone networks over the next few
months, both from the perspective of commercial carriers and commercial
enterprise users.

To tie both current and next generation telephony services together with
other systems and services, we expect to continue using Apennine and
later a new Apennine server based on the GNU Enterprise gnurpc library.
Apennine provides a plug extensible XMLRPC server, and XMLRPC services to
control all GNUCOMM servers will be introduced. This is part of the larger
effort to standardize GNU interoperability between phpGroupWare, DotGNU,
GNU Enterprise, and GNUCOMM around XMLRPC that was announced earlier last
week.

PV Info Server and BayonneDB
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
One project I have chosen to drop from active development is BayonneDB.
This is the database server for realtime transactions in GNUCOMM. The
PreViking Info server exists, is further developed, and uses all the same
protocol interfaces as BayonneDB. There are some places that BayonneDB
may have advantage in raw performance, and BayonneDB may be worked on
later next year, but I simply do not have time to do so currently.

Outline of Bayonne changes
~~~~~~~~~~~~~~~~~~~~~~~~~~
There are several important areas of GNU Bayonne development that are to
be undertaken the next few months. Many of these changes will also be
reflected in Babylon and Olorin development.

One area being thought about is server provisioning. Currently this is
being done with a simple bayonne.conf file placed in the /etc directory.
We are thinking of replacing this with an XML server provisioning file
that can be fetched either locally or from a remote web server. Also, it
should be possible soon to reload provisioning on a running server (one
can already reload provisioning scripts (ccScript) live…).

In addition to configuration provisioning, I hope to improve remote
manageability of Bayonne and to get rid of some of the vast number of
redundant ways of doing things in Bayonne. For example, we now have five
major ways to integrate Bayonne with external services; fifo control,
tcp based sysmon, cgi wrappers, XMLRPC thru Apennine, and oncrpc. We
almost added Corba as well! Much of this redundancy will go.

To simplify administration of live systems, a desktop “monitor” or
management console will be created for Bayonne. Oh, and we will
decouple telephony drivers from Bayonne…

“GNU/”LinuxWorld NYC
~~~~~~~~~~~~~~~~~~~~
I am both speaking at GNU/LinuxWorld NYC next month (about DotGNU), and I
am hosting the Telephony BOF. Last year in NYC we demonstrated GNU
Bayonne in the Intel booth, and this year we will likely do so in a booth
in the org pavilion. I believe a GNUCOMM booth has already been secured
for this purpose. I expect to be available to talk to different people
about what we are and will be doing with GNU Bayonne, and I hope we will
have some interesting new things completed in time to demonstrate.

Where help is needed
~~~~~~~~~~~~~~~~~~~~
We now have a carrier involved in Bayonne development, and realistically
we still do need further support from other commercial vendors and
interested parties. Having OSDL supporting facilities has helped
considerably in overall testing, but we do continue to need
additional support for continued Bayonne development.

One area that needs some additional help is GNU Common C++. We have yet
to be able to fully build native win32 libraries with XML support or build
a complete cygwin target. While I am not particularly interested in a
win32 target for GNU Bayonne, it could be created. More interesting to me
would be to distribute GNUCOMM related desktop components (such as GNU
phone) as widely as possible.

That being said, yes, we may well choose to demonstrate a win32 port of
GNU Bayonne at some future time, primarily to demonstrate the universal
nature of GNU Bayonne as the primary platform for telephony services
creation. I have no current plans to do this, however.

David

Category:

  • Open Source