[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:                   block
Priority:                   normal
Status:                     assigned
Target Version:             1.6.2.0
Asterisk Version:           SVN 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
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-10-05 14:48 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
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
has duplicate       0015886 T38 udptl.c bufferoverflow
====================================================================== 

---------------------------------------------------------------------- 
 (0111869) svnbot (reporter) - 2009-10-05 14:48
 https://issues.asterisk.org/view.php?id=15586#c111869 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 222110

U   trunk/UPGRADE.txt
U   trunk/channels/chan_sip.c
U   trunk/configs/sip.conf.sample
U   trunk/configs/udptl.conf.sample
U   trunk/main/udptl.c

------------------------------------------------------------------------
r222110 | kpfleming | 2009-10-05 14:48:10 -0500 (Mon, 05 Oct 2009) | 25
lines

Allow non-compliant T.38 endpoints to be supportable via configuration
option.

Many T.38 endpoints incorrectly send the maximum IFP frame size they can
accept
as the T38FaxMaxDatagram value in their SDP, when in fact this value is
supposed to be the maximum UDPTL payload size (datagram size) they can
accept.
If the value they supply is small enough (a commonly supplied value is
'72'),
T.38 UDPTL transmissions will likely fail completely because the UDPTL
packets
will not have enough room for a primary IFP frame and the redundancy used
for
error correction. If this occurs, the Asterisk UDPTL stack will emit log
messages
warning that data loss may occur, and that the value may need to be
overridden.

This patch extends the 't38pt_udptl' configuration option in sip.conf to
allow
the administrator to override the value supplied by the remote endpoint
and
supply a value that allows T.38 FAX transmissions to be successful with
that
endpoint. In addition, in any SIP call where the override takes effect, a
debug
message will be printed to that effect. This patch also removes the
T38FaxMaxDatagram configuration option from udptl.conf.sample, since it
has not
actually had any effect for a number of releases.

In addition, this patch cleans up the T.38 documentation in
sip.conf.sample
(which incorrectly documented that T.38 support was passthrough only).

(issue https://issues.asterisk.org/view.php?id=15586)
Reported by: globalnetinc

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=222110 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-10-05 14:48 svnbot         Note Added: 0111869                          
======================================================================