But I personally think that things are improving,
I have a running version that handle 40 000
calls/day.
I trust CommonC++2 & Ccscript, they seem to be bug
free.
As long as this is reliable drivers should not be too
hard to debug.
Features and expectation I am looking
for:
-The multiple drivers support may be
delayed.
-Even if we are working a lot on Globalcall this let
us test the core of Bayonne in the mean
time.
-I think H.323 and SIP will soon become more and more
important I think Bayonne will be really interesting as an IVR
VOIP server.
-Reliable Database support from Ccscript is a key
feature, the one currently in Bayonne is still having bug, I have made my
own and you know this is not something complex and does bring a lot of
Interactivity possibility.
Conclusion, I think keep it simple is the main lead
we shall choose, there is already enough feature to
debug.
If we can tell that most of the basic features are
working as it is the case currently; Bayonne should be easier to start with and
more people will start using it and help.
With the Lucas How-To it is now quite easy to install
and configure Bayonne.
Any body is having problem with Dialogic Globalcall
Drivers in Bayonne?
Julien
-----Original Message-----
From:
address@hidden
[mailto:address@hidden On
Behalf Of David Sugar
Sent: April 5, 2005 9:40 AM
To: Ambar Roy
Cc:
address@hidden
Subject:
Re: [Bayonne-devel] web article about Bayonne
-----BEGIN PGP SIGNED
MESSAGE-----
Hash: SHA1
I had been rather quiet because until very recently
even I had not
reached any final decision on what we would be doing
going forward.
Perhaps I have been quiet for far too
long.
Originally we had some problems starting in 2003, when
we had a party
interested in producing an analog phone system around
voicetronix
hardware. This resulted in a lot of time and
interesting development
spent on that, but at the expensive of loosing focus
on what Bayonne is
and on other things that would have been more valuable
to people, such
as completing the then original openh323 driver that
one contributor
started. Of course, we later learned we could
not use that original
openh323 driver anyway, because the person who
submitted it later signed
agreements with another project which claimed
ownership over his past work.
Around the start of 2004, new work was split into two
trees, a testing
tree I started both to try and restore a better focus
on what Bayonne
is, and based on new work and recommendations of
people who were later
involved on the second tree. This second tree
was already then largely
complete, and included a new solid implementation of
the openh323, and a
new aculab driver. The aculab driver I had no
means to test, and since
the new tree was being maintained and heavily tested
internally by
others with such facilities, I agreed to promote that
new tree as the
new stable release. Given that, I modified the
existing testing tree to
much more closely match the second stable tree, and
bring the openh323
driver that I could test to match the second tree, to
allow for wider
testing of the tree and at least of that new driver in
the process, and
later as a place to get a sip driver going that could
then easily
migrate back to the now similar future stable
branch.
In that the second stable tree was essentially
complete, I was asked to
discontinue the testing tree so as not to confuse
users with two trees
with the introduction of the then promised release of
the new stable
tree. Of course around that time I also was sick
part of 2004 with
Pneumonia, and afterward for other medical reasons, I
could not travel
for much of the rest of last year. Many of the
normal events and
activities I do which involve Bayonne I was completely
unable to perform
or attend. I also moved, and I was kept very
busy much of the remainder
of the year in other areas. For the most part I
was generally
unavailable to many people most of last year as a
result. For that I
assume full responsibility. Of course, in that
commitments were made to
me about introducing the new stable branch, and I
completely trusted in
those commitments, I did not interfere in that
process. I had
considered appointing an interum maintainer as part of
that release
which never happened. As a result, nothing was
accomplished in 2004.
As it was rather clear by the end of 2004 that those
commitments were
not going to be fulfilled, I used what rather limited
time I then had
available to work with a number of people who were
maintaining existing
production sites, and particularly the excellent
people at WS Wireless
in Bologna. Together, we worked on changes
needed to improve and better
support those using the last stable release, and bring
it forward to
support current builds of Common C++ and other updated
and bug-fixed
libraries, a process that continues to this day.
These changes were
limited either explicitly to specific bug fixes
(particularly in the
dialogic drivers, which they use) and the completion
of one feature that
was originally started in the testing branch; audio
conferencing support
in the dialogic drivers.
As I found myself at the start of the year again the
sole maintainer of
Bayonne, I had a number of possibilities going forward, and
rather
limited time for any option I might choose.
Certainly the simplest
option would have been to discontinue Bayonne. But I
felt I could not
do that especially after the incredible help and
support Aymeric gave me
early this year with the SIP driver, and with the
continued support I do
get from people in the community, and we definitely do
have one, such as
Luca, as well as that of people from companies like
the WS Wireless
people, and Gerry Gilmore from
Intel.
The first option going forward was to push the
existing stable branch
forward and perhaps backport some other things from
the testing branch.
Of course, that branch had a lot of odd
inconsistencies from the effort
put into supporting analog phone system cards and from
the then rather
fluid nature of the ccscript core language
itself. It also suffers from
one other key Bayonne limitation; by pushing so much
functionality down
to the driver, and with different people involved in
initially creating
new drivers, each driver now has a very unique design
pattern. Hence,
each new driver added tends to exponentially add to
the difficulties in
maintaining the system as a whole. This is fine
when each driver has
someone separate to maintain it, but becomes
impossible when a large
number of the drivers have to be maintained without
direct access to
every piece of hardware used, and where each driver
must then be
verified for every change being
made.
A second possibility would have been to promote and
continue developing
the testing branch. But while a lot of forward
looking work was started
in it, all that was stopped and then abandoned last
year, as it was
re-made to resemble the new stable branch that never
appeared. Hence,
many key limitations do remain unaddressed, and in
some respects are
worse than even the stable branch, as it has a larger
body of drivers
each with even more different design
patterns.
The third option was to finally radically simplify
Bayonne and
refocus
on what it is supposed to actually do, much more so
than what work was
in progress in the testing branch before being
stopped. As just one
example, while a lot of work had been done in the
testing and missing
new stable release on loading multiple drivers, each
driver maintained
in it's own way it's own managed timeslot segment of
drivers, each coded
in their own way; instead, it would be much simpler to
assign all loaded
drivers over a single contigues timeslot map, to have
them all share
common base classes which run the same core state
machine code, to have
all common audio processing peered in the common
timeslot base rather
than implemented in very different ways in each
driver, and to finally
have a common design pattern for all drivers,
including for the
difficult process of handing off thread deaths out of
the dying thread's
context, which is something that is done in a
different and amazingly
complex way in each and every driver currently.
But this would take
some time, and even further freeze other activities
until completed...
Ambar Roy wrote:
>>I wrote an introduction to Bayonne and IVR services
for the web megazine
>>linuxfocus
(http://www.linuxfocus.org)
>>
>>it's in english:
>
>
http://www.linuxfocus.org/English/April2005/article372.shtml
>
>>and italian:
http://www.linuxfocus.org/Italiano/April2005/article372.shtml
>>
>>the goal is, of course, to promote Bayonne's use in phone
services
>
> Hi Luca,
>
> I read the english version. Excellent
Article!
>
> I have been evaluating bayonne for some time
and here are some reasons why I
> am not being over enthausistic about using
bayonne in
production
> environments:
>
> a. I hardly see any developer activity on
bayonne. I
have been a member of
> bayonne-devel list for some time now and the
message traffic is almost non
> existant.
>
> b. I have seen that most people's queries on
bayonne seem
to go un-answered.
>
> c. I do not see any real community behind
bayonne. I
have been a member of
> this list for the past 3 months and the only
active members seem to be
> yourself, David and Julien. What happened to
everyone else?
>
> d. I have no clue as to how stable is bayonne's connectivity
to telephone
> networks via E1 links using PRI, R2 & C7/SS7
when using dialogic telephony
> boards.
>
> e. What all features are available from the
native scripting language used
> in bayonne.
>
> f. No real description of successful
implementation of bayonne in
telecom
> networks beyond "We are using bayonne!" or "We have
successfully implemented
> bayonne!"
>
> g. Is there any form of commercial support
available for bayonne? Is it
> possible that, if required, i can find
people/companies who are willing to
> work on getting rid of bugs or to implement new
features for a fee?
>
> My company deploys high density IVR systems at
telcos and currently we use a
> proprietory platform for IVR systems. I have been
trying to figure out if
> bayonne is even a viable alternative to our
current system! Our current
> platform may be expensive and proprietory, but
our vendor gives us excellent
> support. Whenever we have faced any problems, our
vendors have helped us big
> time. I have never really felt confident about
what would happen if I face
> problems in a production environment. I have been
following the bayonne
> project for more than 1.5 years now, and I hardly
see any activity. The
> bayonne home pages are also not with any
recent news. The bayonne.sf.net
> page's latest news is from 27th Feb 2004 and on
www.gnu.org/software/bayonne
> the latest news item is from
2003-07-06!
>
> I really think that the bayonne project has not
done much to attract people
> who might be intrested in deploying bayonne in production
environments. Luca
> is doing a great job here, but we probably need
more people doing similar
> activity. Google tends to only turn up old
articles on bayonne :-(
>
> Ambar Roy
> PS: Luca bayonne.sourceforge.org does not lead to
the bayonne
page. It is
> bayonne.sourceforge.net or bayonne.sf.net
;-)
>
>
>
>
_______________________________________________
> Bayonne-devel mailing
list
>
address@hidden
>
http://lists.gnu.org/mailman/listinfo/bayonne-devel
-----BEGIN PGP
SIGNATURE-----
Version: GnuPG v1.4.1
(GNU/Linux)
Comment: Using GnuPG with Thunderbird -
http://enigmail.mozdev.org
iD8DBQFCUpUuJlWtSTiTVsYRAp6xAJ9mOhKSJa71tY5C5ZfbmKGd3JNengCcCy2a
VTv21XsVto6pu0K4Oq56gmI=
=m5PI
-----END PGP
SIGNATURE-----