[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-08-25 15:17 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
====================================================================== 

---------------------------------------------------------------------- 
 (0109626) kpfleming (administrator) - 2009-08-25 15:17
 https://issues.asterisk.org/view.php?id=15586#c109626 
---------------------------------------------------------------------- 
That is correct, and that's why I've asked the reporter to test the tip of
the 1.6.0 branch, and not the most recent released version. There have been
changes in T.38 support *after* 1.6.0.10 was made (and 1.6.0.13/14 were
just security releases so their T.38 support is identical to 1.6.0.10), and
one of those changes was to try to accommodate T.38 endpoints that report
ridiculously small T38FaxMaxDatagram values. This *is* the workaround you
are asking for, but we need testing to ensure that it solves the problem. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-08-25 15:17 kpfleming      Note Added: 0109626                          
======================================================================