David Sugar tells us what’s new in GNU Bayonne (February 28, 2002)
See
http://www.gnu.org/software/bayonne for general information.
1. What, another update already?
2. GNU Bayonne Web Services
3. Applications and Applets
4. Applications for Carriers
5. Plugins Everywhere
6. What to do with gnutelephony.org
7. A GNU SIP stack is born
8. Bayonne-by-Night introduced
What, another update already?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Updated reports are done whenever there is sufficient information to impart, and are not done on any fixed or known schedule. It happened to be a particularly busy week, so there is a much quicker update than usual. In fact, a number of new topics have come up, each of which will have significant impact on GNU Bayonne going forward.
GNU Bayonne Web Services
~~~~~~~~~~~~~~~~~~~~~~~~
In the 1.0 code base we are making GNU Bayonne “http aware”. This was done primarily to support other servers by enabling GNU Bayonne to provide XML formatted documents for system status and, ultimately, to support XMLRPC and make GNU Bayonne servers accessible as a telephony resource for web services development.
When I say web services, I envision a number of things. Imagine going into something like the address book in phpGroupWare, and having your phone dial when you click on phone numbers in an address book entry. Imagine seeing a call history of who called you, and imagine the Bayonne link appearing on customer service web sites to connect you to an agent.
In the beginning, there was Bayonne, but it had only very limited integration. This integration could be achieved thru the command fifo and could be accessed by a web application running on a local server on the same machine thru CGI or similar mechanisms. CGI executables could control the Bayonne server residing only on the same machine.
There were problems with this, of course, since Apache ran under one user id and Bayonne typically under it’s own. To get around this problem, a special “wrapper” was created that could be invoked from cgi and switch from the uid of apache to the uid of Bayonne before calling IPC services. However, again, we were still on the same machine. To enable remote access to Bayonne resources, one had to setup a local web server on the Bayonne machine and then hand create a web service that could invoke cgi and return usable results.
To more fully enable standardized web services, we choose to support XMLRPC. However, while XMLRPC standardized the mechanism for exchange between local IPC of a given GNUCOMM telephony server and a generic external representation for web services, it still required a web server to host it, and translation logic. In some prior GNU Bayonne releases, this role was filled by a separate master server called Appenine. Appenine would sit above the entire GNUCOMM tree and offer XMLRPC to the world, while at the same time using IPC services to communicate locally with things like Bayonne.
The problem with this approach had been twofold. First, none of the GNU Bayonne IPC mechanisms at the time were fully bidirectional, hence one would have to come up with clumsy integration methods that relied on the Bayonne fifo and memory mapped blocks. Second, this meant two distinct layers were involved in handing off XMLRPC calls, with all the inefficiencies this involved.
In the 1.0 source tree, we have chosen to support a new TCP mechanism for IPC and control. One can telnet to a running GNU Bayonne 1.0 server and manipulate it live and interactively. This new mechanism was modified so that it could support http requests alongside interactive telenet sessions and so now GNU Bayonne can respond to http requests directly as well.
What we wish to do with http in GNU Bayonne is enable integration of telephony aware web services rather than support browsers. To accomplish this, GNU Bayonne’s http support will typically be used to emit parsable XML documents rather than browsable HTML pages. This will also enable one to create administrative web service front ends for GNU Bayonne which retrieve, parse, and provide a local browser presentation of the server information in any manner desired, rather than hard coding a specific data presentation directly browsable from the server itself. I believe we need to separate presentation from content and have presentation (for browsers) occur outside of the GNU Bayonne servers.
I have also added XMLRPC parsing capabilities to GNU Common C++ a few revs back, and I plan to use this to accept XMLRPC requests as well as provide XML content for other services to use. XMLRPC and XML parsable documents together will be delivered thru this interface. A single “status” page will be provided in http as a “text/html” so that one can use a browser to quickly stat a running server, and a few special url requests may be used to provide the GNU Bayonne “logo” and standardize a Bayonne “link” one can toss onto a web page for quickly building GNU Bayonne click-to-dial applications.
Since one can potentially do interesting things with this new mechanism, we did not want ordinary users over the internet submitting requests to running GNU Bayonne servers that happen to sit on an open port. So, GNU Bayonne can support authentication, and uses the same user local “group bayonne” password entry set the telnet mode command monitor does. Some URL’s, like say the “logo image”, do not require protection, and will be accessible with unauthenticated requests. Others of course do require authentication to access.
Since we have an XML schema in GNU Bayonne now, the “gnucomm” schema used for the config file, this schema will be extended and used also for the standard document representation for supplying XML document requests that contain server information as well. We really also need to provide a complete DTD document for defining “gnucomm” as a distinct dialect.
Applications and Applets
~~~~~~~~~~~~~~~~~~~~~~~~
We had just started a major push for GNU Bayonne applications late last year when, in a meeting held in London, it was decided to put that on hold for awhile so that we could organize a 1.0 release and integrate with the phonestreamer drivers. Now that the 1.0 server tree is looking more stable, it is time to again focus on applications. I do not believe we can have a successful 1.0 release of GNU Bayonne unless we provide at least some applications anyone can use right out of the box after installing the server.
A Bayonne “application”, as defined in Bayonne “1.0”, essentially is a service script, a set of related voice prompts in a common library directory, and, possibly a supporting DSO module. An application might include a web services/front end component as well, and possibly a database. These are not necessarily trivial to setup, but I think are still appropriate to bundle as needed. A Bayonne “application” might also be made available as a completely separate package. In fact, I recall Rich Bodo is doing some work to use “stow” to manage installation and removal of Bayonne applications.
A Bayonne “applet” could be thought of as a set of scripts or modules and/or voice prompts used to deliver some small piece of an application that might, to some extent, stand-alone, but really, is meant to be used within or as part of building other applications.
An example of an “applet” might be found in the current “pinredirect” module found in the Bayonne 1.0 tree. This is meant to provide a simple mechanism to create and manage a small number of pins in a running Bayonne server. In particular, such an applet might be used by a company to control access to enable employees to make calls redirected thru an outside line, and hence, the name “pin redirect”.
When we consider applications for use with Bayonne, several categories come to mind. One area involves applications for commercial carriers and wireless service providers, which I will talk about shortly. More traditionally, people think about enterprise applications like voice mail, unified messaging, v-commerce, and customer relations management, which relate deeper into GNU Enterprise and phpGroupWare, and which I am going to cover at a later time. We also in time will explore and provide working solutions for vertical markets, like hotel-motel, and complete office phone systems using GNU Bayonne.
To do applications we also need people to volunteer to record and provide voice prompts for them. If you are interested in being a “voice” of GNU Bayonne, I would be interested in hearing from you.
Applications for Carriers
~~~~~~~~~~~~~~~~~~~~~~~~~
I currently have three applications in mind to complete, test, and use to demonstrate how GNU Bayonne may serve the needs of commercial carriers, both for providing wired and wireless services. At one point we actually had facilities available to us from a US based carrier to test these kinds of applications, but at the time we did not have functional PRI span support which we do now, and so we could not take advantage of those facilities.
I am looking for commercial carriers that might be willing and interested in permitting testing and deployment of GNU Bayonne on live spans with outside dialable numbers so we can test and demonstrate these services properly. We have facilities at OSDL, but these facilities do not include outside dialable spans, at least at this point. We are in the process of establishing a grant program for GNU Bayonne, and it may be possible this could help provide some funds for such testing. If commercial carriers wish to contribute to GNU Bayonne development in other ways, this could also be a means for that to happen.
The three applications I currently envision bundling initially with GNU Bayonne are operator redirect services such as used for automated (or customized) directory assistance services, voice mail hosting (vmhost), and prepaid calling (such as for prepaid cellular or debit cards).
Voice mail hosting should be explained further. This can be thought of as a simplified “voice mail”, as it does not need to deal with enterprise voice mail features like user directories, copying and forwarding messages between mailboxes, etc. As such, it is meant for hosting of mailboxes for individual subscribers alone.
Prepaid calling is well understood, and any GNU Bayonne prepaid solution will need to at least be aware of, if not initially address, csr and end user web services for things like administration and account review, billing (potentially thru clearing houses), account balances, pin databases, and recharge services, in addition to the voice application services supplied thru a GNU Bayonne server itself. I do not look at it as a small or simple application, and some parts of it can easily touch upon things being done in both GNU Enterprise and phpGroupWare. For the 1.0 release, I am only concerned with having appropriate prompt libraries, a model prepaid application script, and DSO support for database integration. I do expect by the end of the year at least two vendors will be providing complete GNU Bayonne based prepaid solutions.
Plugins Everywhere
~~~~~~~~~~~~~~~~~~
One of the things we have done moving into the 1.0 source tree was to remove functionality from the core server that is not commonly used and make that functionality available instead as plugins. This has allowed the base server to be simplified, and has reduced feature creep out of the core server.
Things that are plugins today include the “request” command, which used to support setting of scheduled jobs. Setting scheduled jobs is not commonly needed, although it is a very useful feature when it is. The new plugin for this in 1.0, “submit”, actually goes further in that scripts can now manage jobs they create and get notification when jobs actually run. The “scheduler” is also a feature that is not essential or used in dedicated applications and will be re-introduced as a plugin.
The entire class tree for plugins had been greatly simplified in the 1.0 source tree. We are also placing a lot more emphasis on plugins for extending GNU Bayonne servers, especially for creating applets and useful services. If anyone has a good idea for new plugins, I would be happy to hear it.
What to do with gnutelephony.org
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I acquired this domain awhile ago because it seemed neat and was available. However, I have not done very much with it yet. One idea I have is to hand out the prestigious “@gnutelephony.org” email address aliases for project contributors and such. Another thought had been to create a portal site for GNU Telephony related projects, although, also keep in mind, there already is a linuxtelephony.org, and a voxilla.org; does the world really need a third infrequently maintained site??
One idea had been to use it to demonstrate GNU Bayonne portal concepts, and now, web services. This I think I might actually do. Also, I am thinking of using it for the things I normally use bayonne.myip.org for as the master mirror site. If anyone has a specific suggestion or proposal for gnutelephony.org, I would be happy to hear it.
A GNU SIP Stack is born
~~~~~~~~~~~~~~~~~~~~~~~
oSIP, the work of Aymeric Moizard, has officially become the newest GNU package as of Yesterday. oSIP offers a state of the art and highly compatible SIP stack available under the L-GPL, and will make it easier to introduce standardized telephony services built on top of GNU.
I was quite pleased to see this finally happen, as I think oSIP will have a significent role on GNU Bayonne development going forward this year. It will of course be an essential component of the Olorin server. However, oSIP is quite capable of being used to create client applications as well as servers. Having a standard library implimentation of SIP in GNU should make it all the more easier for other GNU applications become telephony enabled.
Bayonne-at-Night Introduced
~~~~~~~~~~~~~~~~~~~~~~~~~~~
To facilitate development of GNU Common C++ “2” and the Bayonne 1.0 source tree, I have now made nightly tarball builds of the current cvs trees available. I expect to introduce prebuilt binary packages to Bayonne-at-Night as well soon. These were made initially available from ftp://bayonne.myip.org/pub/nightly, although they should now be available from GNU Enterprise as well (see www.gnue.org for details).
