[Asterisk-Dev] Features requests on bugs.digium.com

Josh Roberson twisted at indigent-networks.com
Fri Dec 31 14:17:26 MST 2004


Lee Howard wrote:

> On 2004.12.31 06:05 Darren Nickerson wrote:
>
>> I think the aggressive closing of bugs, and rejection of feature 
>> requests has already had an impact on Asterisk, and will hinder it 
>> significantly in the long run.
>
>
> If it's worth anything to anyone, I agree with Darren on this.  Allow 
> me to take it a step further, though.  I've watched Asterisk project 
> behavior rather closely in the last year, and I

-snip- Already covered.

> I'll give an example, and I hope that it's not a trite one, but 
> because I'm involved with faxing so much it's the one I'll choose to use.
>
> Some time ago a friend of mine filed a bug report that Zap's faxdetect 
> wasn't detecting incoming faxes from certain kinds of fax machines.  
> Personally I'm not a strong believer in automatic fax detection 
> because inevitably it fails with some fax machine or another, 
> especially the (nowadays few) analog kind that are "listening" for 
> ringback rather than "beeping" some tones.  However, my friend does 
> use faxdetect, and he uses it somewhat religiously for his own 
> purposes.  And, inevitably he encountered a number of fax machines 
> that weren't detected as such by faxdetect.  So what did he do?  He 
> filed a bug report with Asterisk, of course.  And then he went through 
> the process of interacting with the bug marshals, running tests, 
> attaching traces, etc.  And in the end it was determined that these 
> fax machines weren't making the "proper" and normal fax tones that are 
> expected.  (If that wasn't already obvious enough.)  And because the 
> tones weren't "proper" the issue was determined to be "not Asterisk's 
> problem", and the report was closed at that.

So the issue here is wether or not we support the standards, AND 
everything else;  I think you will find that there is no way for us to 
test, fix, impliment, and conform to every single little thing out there 
in the world, let alone fax machines, and the only way to make this work 
properly would have been for someone in the project, to go out with 
their own money, purchase the exact make/model (if it was still made) of 
that particular machine, and build up the DSP code to recognize that 
particular tone.  Now, that's just not something you should expect out 
of a free project. 

> Now, I wonder what we expect my friend to do.  Stop using faxdetect?  
> Harrass these fax machine manufacturers into producing a fix and 
> replacing these people's fax machines?  Tell the fax machine user to 
> get a different kind of fax machine?  Well, none of these really are 
> viable solutions.  Understand that the opinion of the fax sender is 
> always, "I can send faxes to everyone else without any problem.  It's 
> not my fault you can't get them.  Maybe I should just avoid this 
> headache by not doing business with you."  That the fax machine could 
> be detected is clear, so it's not really a technical problem where 
> this fax machine is getting mistaken as my Aunt Mabel's squeaky 
> voice.  In this case it ended up appearing to be a choice made that 
> Asterisk will not ever support faxdetect for these fax machines.  And 
> of course, my friend doesn't want to lose his customer, and so he sets 
> up a different faxing route for them, certainly without faxdetect, 
> possibly without Asterisk.  And this "selective stagnation" is where 
> Asterisk is being impacted. 

> If, on the other hand, my friend had developed a patch to Asterisk 
> which would have permitted the detection of these fax machines, then 
> I'm most certain that it would have been readily accepted into CVS 
> without any arguments about it supporting "broken" fax machines.  So 
> it seems to be a double-standard: happy to allow code contributions, 
> but not happy to admit contributions of mere observation.  Maybe I'm 
> wrong in this assumption, but to make sense of this double-standard I 
> had merely assumed that the handling of the bug tracker was done under 
> Digium's eye, and thus it was Digium's business interests that were at 
> play in the decision making on the bug tracker, that those of us who 
> disagreed with the handling of the bug tracker should set up our own 
> bug tracker, and that we should maintain our own fork, if we dare.  
> But, maybe I'm just looking for conspiracy where there isn't one.  
> Maybe there is no reason behind the madness.

If they had developed a patch to permit support of these, then yes, 
assuming it met the guidelines and was disclaimed, it would have 
possibly gone in.    You are mistaken in one regard - we do happily 
accept observations, and reports of things not working properly.  
However, if it's not something that is going to be fixed, wether it's 
due to the fact of it being just not feasable, or just downright not 
going to happen, it will get closed. 

As for the handling of the decisions on the bugtracker, they are 
entirely up to Mark, and the other bug marshals.  Digium provides the 
resources for this applicaiton, but it is not under their control.  Any 
issue that is related to digium (hardware issues, techincal support 
issues) are generally referred off of the asterisk bug tracker, and sent 
directly to digium.   Keep in mind, this project IS an open source 
project, and most of us who work on this project are NOT financially 
backed by it - it's a volunteer job.   And as I've stated a few times 
before - If you don't like what's going on, GET INVOLVED.  Complaining 
does nothing but get peoples feathers ruffled, especially when they're 
doing this out of their own free will. 

> If the goal is world domination you cannot selectively avoid appealing 
> to some of those who would choose to use Asterisk.

> Lee.





More information about the asterisk-dev mailing list