Hi Anders,
Glad that you answers, I was not expecting that :)
My response is below, inline.
On Sunday 09 November 2008 14:35, Anders Baekgaard wrote:
> Hello Anton,
>
> You write that chan_ss7 is intentionally filled with
> bugs, and you mention one bug, about the one way audio
> problem, that you have reported to this mailling
>
> list. In a mail to this list, dated 2008-09-15, you write:
> > I have to note that a while ago one edge of the problem
> > was in IAX connections between systems - so IAX was
> > giving oneway for a certin amount of calls - and
> > switching to SIP resoved it - but now it might be just
> > chan_ss7 related.
>
> If both IAX and chan_ss7 gives one way audio, the problem
> could be somewhere else. I do not understand why you
> think this is a bug _intentionally_ left in chan_ss7.
just recently I noted one way audio with chan_ss7, which was
definitelly non-IAX2 based, since I tested it by switching
live from IAX2 call to SIP - and one-way audio was present
on the 2-nd CIC for the moment of capture, and which gone
away after asterisk reload.
My assumptions that bugs were intentionally left in chan_ss7
are based on several things
1. the following DICEA statement:
"This version differs from the free
download version by having a large number of stability
fixes and enhancements"
2. the following code from chan_ss7-1.0.95-beta, transport.c
#if 1
sprintf(devname, "/dev/zap/%d", zapid);
fd = open(devname, O_RDWR);
if(fd < 0) {
ast_log(LOG_WARNING, "Unable to open signalling link
zaptel device %s: %s\n",
devname, strerror(errno));
goto fail;
}
#else
devname = "/dev/zap/channel";
fd = open(devname, O_RDWR);
if(fd < 0) {
ast_log(LOG_WARNING, "Unable to open signalling link
zaptel device %s: %s\n", devname, strerror(errno));
goto fail;
}
which clearly does not allow the regular user to use ofve
8E1 since ZAPTEL does not generate over 8xE1 zap devices.
and if one will change if 1 to if 0 to allow the second part
of the code to compile, it's C syntax is intentionally left
wrong, since you cant compile it like this
devname = "/dev/zap/channel";
but can like this:
sprintf(devname, "/dev/zap/channel");
and as a C programmer you cant claim that you have not
checked that part of the code, since it's too obvious.
I've provided the patch to the mailing list a long ago, and
as I remember, after this I found this section added in the
chan_ss7 code, next release. But appeared intentionally
non-compilable.
3. You reluctant acceptance of the bug-reports and patches,
which makes thinking, that you already aware of this
problems, or already fixed them and there is no point to
communicate regarding bug-reports
>
> You write that we have not included the patch published
> on this list for support of zaptel new style addressing.
> But there has been support for this since version 1.0.0,
> released november 2007. I am not aware of any problem
> with this, and I am not aware of any patches that solve
> bugs that are not already fixed in the released versions
> of chan_ss7. I do not understand why you think that the
> patch is _intentionally_ left out.
Explained above
>
> Your accusation that we intentionally leave bugs and
> charge people excessive amount of money to fix them, is
> simply not true. I receive very few real bug reports, and
> I do not see many bug reports on this mailing list.
> chan_ss7 is stable and used in production by really many
> users around the world.
oneway audio problem exists since the first version of
chan_ss7, I have been using.
>
> In december 2007 I had email correspondance with you
> where you asks for help to setup an 8 E1 server. I send
> you an offer with my best estimates at that time (2-4
> hours for code changes, optionally 5-8 hours if you wants
> us to log in to your system and install/configure/test
> the solution, 170 Euro/hour). This is considerably more
> work than changing two lines of code. I do not understand
> why you write that we charge you 2000 Euro for two lines
> of code.
plus testing hours etc and minimum hours, it was rough
numbers and the total number is somewhere around 2000.
But it's not the point.
>
> You write that Dicea is breaking existing licenses. We
> obviously will not do anything not legal, or not comply
> with existing licenses. chan_ss7 comes with GPL license,
> and the supported version comes with the same license.
> The purpose of offering a supported version is to provide
> professional support for the users that want it, and to
> finance Diceas continued development of chan_ss7. The
> work we do on chan_ss7 is mainly due to personal
> interest, but we want to have the work partly financed.
So, than what you write above is against what is was given
on DICEA WEB site. I see you have already changed that
pages in DICEA site, and now even statement above looks
like "having number of enhancements", instead old
statement, given above. We all can do 2+2
I'm sure you don't want to show that i'm wrong, and just
publish your "fixed" version of chan_ss7.
>
> The mail you sent to this mailing list is your response
> to somebody noting that Dicea has an SMS solution. We
> sell support and SS7 related software products, this also
> helps finance the effort put into chan_ss7. As a user,
> you are also benefitting from this business model.
Existence of the chan_ss7 allowed me to have ss7 connection
for a long time, sometimes buggy, oneway audio, but the
fact is: i use it, and there was no comparable alternative
for a long while. And I thank very much all of chan_ss7
developers for this. But, my point on the bugs is clear,
and it looks very much the way I have explained.
And sad, but I know users who dropped chan_ss7 after
intensive test and went for proprietary solutions, like
SANGOMA SMG - just because the needed more stability.
I'm not against of the any commercial support or even of the
proprietary enhancements to a chan_ss7 (note that GPL does
not allow library linking to a non-GPL code, and there is a
reason for it), if it's done properly. But this can be a
long question.
>
> I have maintained chan_ss7 for several years, and I have
> got a lot of positive feed back from users. There are a
> few exceptions like you.
Yes, there must be exceptions, sad to say, but any my bug
reports, both to sifira and dicea was not considered at
all. With this approach, chan_ss7 is going to repeat the
history of channel ooh323c - by obj-sys which was not-bad,
but they did the same sort of support - too expensive and
too buggy, and than other open channels won.
>
> I hope this mail clears the issues raised.
>
> Best regards,
My best wishes,
Anton.
|