[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 10:33 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
====================================================================== 

---------------------------------------------------------------------- 
 (0109590) globalnetinc (reporter) - 2009-08-25 10:33
 https://issues.asterisk.org/view.php?id=15586#c109590 
---------------------------------------------------------------------- 
To further explain the issue above.  Any released version beyond 1.6.0.10
does not allow a T.38 connection negotiate correctly to the SIP provider. 
In the versions with the revised T.38 stack you will see:

[Jul 30 01:58:13] WARNING[16385] udptl.c: UDPTL asked to send 41 bytes of
IFP when far end only prepared to accept 31 bytes; data loss may occur.
[Jul 30 01:58:13] ERROR[16385] udptl.c: Buffer overflow detected (48 + 131
> 176)
[Jul 30 01:58:13] NOTICE[16385] udptl.c: UDPTL Transmission error to
66.62.196.38:59166: Message too long
[Jul 30 01:58:13] WARNING[16385] udptl.c: UDPTL asked to send 41 bytes of
IFP when far end only prepared to accept 31 bytes; data loss may occur.

This causes the symptom hulber reported above.  I believe that this is
also reported in issue 15586.  The Sip truck provider is using SONUS.  I
believe this to be an issue with them but as usual they are big we are
small so it is up to us to create a work-around. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-08-25 10:33 globalnetinc   Note Added: 0109590                          
======================================================================