GNU Bayonne development as presented at the 2005 Open Source Telephony Summit held in Chicago

1. Free Software/Open Source Telephony Summit 2005
Developing GNU Bayonne
* What is GNU Bayonne and how is it used?
* How do you start large and complex FS/OS projects?
* History and design elements of Bayonne architecture
* What we learned about subdividing projects from Bayonne
* Where we are today in Bayonne
* Future plans for Bayonne development

2. Free Software/Open Source Telephony Summit 2005
What is Bayonne & How is it used?
* Free software for computer telephony
* Bayonne as a computer telephony toolkit
* Bayonne as a script driven IVR
* Embedded adjuncts and Legacy Integration.
* High port count applications; IDT Debit
* IVR as a network service; voice broadcasting
Port density
High Cap.
Bayonne
Embedded.
Bayonne
Community
? Yate ?

3. Free Software/Open Source Telephony Summit 2005
From Concept to Production Release
1991 Year of Linux Kernel,
first ACS design, under QNX...
1997 DBS Server; CTI as Free
Software! QNX had no future...
1999 year of OpenH323 and
also ACS; C++ everywhere!
2001 Transition to Bayonne
and mature libraries
* Clear articulated design
* Building upon past work
* Why we choose C++
* Scalability & threading
* Logical breakdown of coding
* Why free software licensing & Community?
1995 U.S. Federal Govt telecom
infrastructure goes (gnu/)Linux!
2004 First Telephony Conf!
sip/h323 drivers in Bayonne

4. Free Software/Open Source Telephony Summit 2005
Hallmarks of Bayonne Design
Why our own traffic engineered scripting language:
* parallelism & scaling to 1000 concurrent ports (and above)
* very tight control of cpu execution
* reduction of heap memory fragmentation
* non-blocking script operations and program execution
* non-blocking reload of application scripts.
Abuse of C++ and other oddities
* pre-linking by exporting process images
* plugins and mapped constructors
* plugins mapped to server image do not need to relocate!
* forced inheritance in scripting and state machine logic.
* Abstraction of telephony hardware

5. Free Software/Open Source Telephony Summit 2005
Dividing up the puzzle
* Large project as a whole of interest to very small number of people
* Finding parts of a project that have wider interest and spinning those off into
separate packages.
* Separate packages means separate and simplified component debugging.
* Large projects already often depend on other external packages so additional
dependencies that are locally controlled does not add to complexity.

6. Free Software/Open Source Telephony Summit 2005
The GNU Bayonne components
Current Component Packages:
* GNU Common C++ “2” - core c++ threading, sockets, etc
* GNU ccAudio - c++ audio manipulation
* GNU ccScript - inheritable script engine
* GNU ccRTP - high performance rtp protocol library
Future and Soon-to-be Updated Component Packages:
* GNU ccAudio2 - added standalone uses, fully endian aware!
* GNU ccScript3 - core Bayonne code moved into script engine
and rigorously enforce scripting syntax
* new GNU phrasebook library for localized language voice prompts

7. Free Software/Open Source Telephony Summit 2005
Where we are today...?
Current development trees:
* Production branch, used worldwide, limited changes over time
* “Stable” Branch; OST Development
* Individual per customer branches
* “testing” Branch for future production releases
Problems in Bayonne today (many not solved in testing branch):
* Too many trees; customer branches are often changes lost
* Lack of rigorous spec for core scripting language itself
* many script side effects and script debugging issues
* Over-engineered and tuned for corner cases only
* Too many hard-coded limits
* Mission creep outside of core IVR functionality
* Driver development model very complex
* Lack of supporting gui ide and other infrastructure projects

8. Free Software/Open Source Telephony Summit 2005
Immediate development goals underway
Reverse library consolidation of stable and testing branches:
* ccScript3 - externalize Bayonne database & script extensions
* ccaudio2 - externalize most Bayonne audio processing
* phrasebook - externalize Bayonne voice libraries for use by others
Redesign server around self contained IVR engine library:
* standardize state & script extensions rather than per driver
* move most driver state machine code into common base class
* easy external build of telephony driver plugins (fix licensing issues)
* simplify server debug and testing starting with ivr engine library
* Bayonne everywhere! xBSD, Solaris, HP-UX, OSX, even W32?!
Eliminate fixed constants:
* no more 1000 port capacity limit!
* remove odd symbol size restrictions

9. Free Software/Open Source Telephony Summit 2005
Other possible future development goals
GNU ccScript3 related enhancements:
* all new C++ abuses! Sideway class inheritance
* split of script library so drivers inherit core runtime only
* server can inherit language spec or run VoiceXML framework
* multi-homed scripts used for project oriented ide & exec environment
GNU ccAudio2 related enhancements:
* framework for ogg-vorbis, mpeg audio, and other codecs
Other fun and possible infrastructure projects:
* bayonneide, common infrastructure for other projects
* telephony panel applets for call agents for use with Yate & Bayonne
* gui administration interface, using Yate protocol?
* specific pbx legacy integration servers derived off Bayonne core?
* web based call accounting/billing system for Yate?

10. Free Software/Open Source Telephony Summit 2005
Some longer term thoughts...
ccScript3
Common C++
Phrasebook
ccAudio2
Bayonne
CTI Server
Drivers
ccRTP/yartp
yass/oh323
Bayonne
XML Server
Bayonne VoIP
script engine
Troll Gateway
Server
Drivers
Other IP
Telephony
Servers
(Yate, etc)
* Bayonne split into
CTI server & VoIP
IVR services
* Legacy drivers
moved to Troll
and maybe yate? softphone
client

11. Free Software/Open Source Telephony Summit 2005
Additional Resources
HTTP://www.gnu.org/software/bayonne
HTTP://yate.null.ro
HTTP://www.gnue.org
HTTP://www.gnutelephony.org (coming soon)
HTTP://www.gnu.org/software/commoncpp
mailto:dyfet@gnu.org