[asterisk-bugs] [Asterisk 0015586]: [patch] Failure to negotiate T.38

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=15586 
====================================================================== 
Reported By:                globalnetinc
Assigned To:                kpfleming
====================================================================== 
Project:                    Asterisk
Issue ID:                   15586
Category:                   Channels/chan_sip/T.38
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
Asterisk Version:           SVN 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-07-26 15:57 CDT
Last Modified:              2009-09-02 09:26 CDT
====================================================================== 
Summary:                    [patch] Failure to negotiate T.38
Description: 
To implement T.38 on most ATAs their is a reinvite required.  In the
process of gatewaying the T.38 negotiations the Asterisk server is not
doing this correctly.  On versions past 1.6.0.10 it does not even send the
same ports on the RTP streams to both parties.  

Every version past 1.6.0.10 fails
1.6.0.11
1.6.1.0
1.6.1.1
1.6.2.0-rc

This also includes the new T.38 stack that is is being introduced. in the
SVN tree of 1.6.1.1 and 1.6.2.0
====================================================================== 

---------------------------------------------------------------------- 
 (0110024) globalnetinc (reporter) - 2009-09-02 09:26
 https://issues.asterisk.org/view.php?id=15586#c110024 
---------------------------------------------------------------------- 
I have uploaded a patched version of udptl.c.  Sorry I did not create a
dif.  Before I patched it the code was shrinking the IPF size if it did not
have a value in the max_datagram.  This would cause it to get smaller as
reported by the debug lines I entered.

[Sep  2 01:13:12] NOTICE[1657]: udptl.c:760
calculate_far_max_datagram_limit: UDPTL T38FaxMaxDatagram far end reported
to accept 200 bytes.
[Sep  2 01:13:12] NOTICE[1657]: udptl.c:761
calculate_far_max_datagram_limit: UDPTL T38FaxIFP far end reported to
accept 83 bytes.
[Sep  2 01:13:12] NOTICE[1657]: udptl.c:797 calculate_far_max_ifp: UDPTL
far end ERROR CORRECTION reported as 2 .
[Sep  2 01:13:12] NOTICE[1657]: udptl.c:798 calculate_far_max_ifp: UDPTL
IFP far end calculated to accept 48 bytes. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-09-02 09:26 globalnetinc   Note Added: 0110024                          
======================================================================