[asterisk-bugs] [Asterisk 0016999]: Bug in Calculating T.38 far max IFP?

[Asterisk Bug Tracker]

The following issue has been SUBMITTED. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16999 
====================================================================== 
Reported By:                jasmin-annika
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   16999
Category:                   Core/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           1.6.2.5 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-03-09 14:21 CST
Last Modified:              2010-03-09 14:21 CST
====================================================================== 
Summary:                    Bug in Calculating T.38 far max IFP?
Description: 
Hi,

after having some problems with far_max_ifp, I noticed, that in the case
of a supplied value of max_datagram (from the far end) of "200" the
far_max_ifp is only 60.

When I unterstand the comment of the calculate_far_max_ifp function in
udptl.c correctly, it should try to produce a value greater than 80
(through decreasing the EC entries), but keep one EC entry in any way.

So in our example of 200 (far_max_datagram) the correct result should be
an IFP of 96 I think. (the main data (96B), One EC entry (96B), 8 Bytes
other Info).
But the function produces a value of 64 (the 5% extra space added later is
not considered), but this value is smaller than 80 and we have more than
one EC entry (exactly space for 2 of them, but the variable value is "1"
(which is also incorrect)). Pls see additional information for code example
and fix proposal.

I hope the calculations are correct and I am not telling nonsense ;-)

Thanks
Jasmin
 
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-03-09 14:21 jasmin-annika  New Issue                                    
2010-03-09 14:21 jasmin-annika  Asterisk Version          => 1.6.2.5         
2010-03-09 14:21 jasmin-annika  Regression                => No              
2010-03-09 14:21 jasmin-annika  SVN Branch (only for SVN checkouts, not tarball
releases) => N/A             
======================================================================