[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 18:07 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
====================================================================== 

---------------------------------------------------------------------- 
 (0111886) kpfleming (administrator) - 2009-10-05 18:07
 https://issues.asterisk.org/view.php?id=15586#c111886 
---------------------------------------------------------------------- 
You are misunderstanding what the changes do; if you do *not* set
'maxdatagram' in sip.conf for a peer, then the normal SIP/SDP processing is
done, and the T38FaxMaxDatagram value provided by the peer is respected.
That is why when the peer sends you 'T38FaxMaxDatagram: 72' you will see
buffer overrun errors from udptl.c, and it is also why the errors from
udptl.c show '72' as the buffer size. When you do a 'sip show peer' and it
says "T.38 MaxDtgrm: -1" that *only* means that you have not chosen to
override the value provided by the peer; 'sip show peer' does not show the
'info from the sip/sdp header', it shows peer configuration information,
not per-call information.

If all your SIP providers/FAX servers are sending very small
T38FaxMaxDatagram values, then yes, you'll need to set 'maxdatagram' in
sip.conf (which you can do in the [global] section if you like, then it
will automatically apply to all peers). This is necessary because for T.38
recommendation compliant endpoints, when they tell us their MaxDatagram
value, we *must* respect it, otherwise we risk sending them overly large
packets that could cause transmission failures or crashes. In spite of
this, there are many broken endpoints that send incorrect values for this
parameter, and so I've provided a workaround. Using this workaround means
your system *might* send them a packet that is too large for them to accept
(depending on how high you set 'maxdatagram'), but there is nothing that
you or I can do about that, because they did not properly tell you what
they are able to accept.

I'm glad your FAXes are now working properly, and I appreciate your
willingness to stick with this and provide test results; many of these
problems are very hard (or impossible) for us reproduce in our
offices/labs, so we need real-world testers to provide feedback. Thanks! 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-10-05 18:07 kpfleming      Note Added: 0111886                          
======================================================================