[asterisk-bugs] [Asterisk 0015586]: 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:                   Codecs/General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
Asterisk Version:           1.6.1.1 
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-21 14:26 CDT
====================================================================== 
Summary:                    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
====================================================================== 

---------------------------------------------------------------------- 
 (0109467) kpfleming (administrator) - 2009-08-21 14:26
 https://issues.asterisk.org/view.php?id=15586#c109467 
---------------------------------------------------------------------- 
Your comments are confusing; first, let me address the simple one... you
say Asterisk does not send the same ports on the RTP streams to both
parties. RTP is not used for T.38 FAX, UDPTL is used, but in spite of that,
since Asterisk is a B2BUA, there is no need nor expectation that the two
channel legs involved will use the same port numbers for their UDPTL
streams.

Now, on to the real issue: Asterisk sent an INVITE with a
T38FaxMaxDatagram value of '165', and a T38FaxUdpEC value of
't38UDPRedundancy'. This means that it is prepared for (and expects) us to
send redundant IFPs in our UDPTL frames as an error correction mechamism.
The default in the T.38 recommendation, and in Asterisk, is to send 3
redundancy frames. To accommodate this situation, Asterisk's UDPTL code
devices the maximum datagram size the endpoint can accept by the number of
IFPs we have to be able to send, subtracts a small amount for overhead, and
uses that to ensure we are never supplied an IFP that we won't be able to
fit into the UDPTL frame.

Since you didn't include a full packet trace (with the originating T.38
INVITE that caused Asterisk to send a T.38 INVITE to the Linksys device),
we can't see what the Sonus endpoint sent, but I suspect it sent a small
T38FaxMaxDatagram value, which caused Asterisk to have to do the same
thing. In essence, this is a problem with the incoming INVITE, but you'll
have to post a full packet trace (as an attachment, not a bugnote) to be
able to verify that. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-08-21 14:26 kpfleming      Note Added: 0109467                          
======================================================================