[asterisk-bugs] [Asterisk 0015586]: [patch] Failure to negotiate T.38

Asterisk Bug Tracker noreply at bugs.digium.com
Mon Oct 5 16:49:22 CDT 2009


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 16:49 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
====================================================================== 

---------------------------------------------------------------------- 
 (0111879) globalnetinc (reporter) - 2009-10-05 16:49
 https://issues.asterisk.org/view.php?id=15586#c111879 
---------------------------------------------------------------------- 
This only works with
t38pt_udptl=yes,redundancy,maxdatagram=400

thne though the sip header is:
<--- SIP read from UDP://216.166.168.17:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 216.166.168.6:5060;branch=z9hG4bK294d6925;rport
From: "unknown" <sip:unknown at 216.166.168.6>;tag=as2ac118b6
To: <sip:216.166.168.17>
Call-ID: 4525aeae092f0b53423d2c3439a39756 at 216.166.168.6
CSeq: 102 OPTIONS
Contact: <sip:IPFax at 216.166.168.17:5060>
User-Agent: Net Satisfaxtion/IP_FAX-8.5.4716.620
Content-Type: application/sdp
Content-Length: 287

v=0
o=IPFax 1254778879 1254778879 IN IP4 216.166.168.17
s=SIP Fax Call
t=0 0
m=image 0 udptl t38
c=IN IP4 216.166.168.17
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:200
a=T38FaxMaxDatagram:72
a=T38FaxUdpEC:t38UDPRedundancy


the peer shows as
  T.38 support : Yes
  T.38 EC mode : FEC
  T.38 MaxDtgrm: -1

if you just use t38pt_udptl=yes and you get these errors

[Oct  5 15:45:47] NOTICE[3392]: udptl.c:1010 ast_udptl_write: UDPTL
Transmission error to 216.166.168.17:49154: Message too long
[Oct  5 15:45:47] WARNING[3392]: udptl.c:997 ast_udptl_write: UDPTL asked
to send 51 bytes of IFP when far end only prepared to accept 12 bytes; da.
[Oct  5 15:45:47] ERROR[3392]: udptl.c:291 encode_open_type: Buffer
overflow detected (53 + 57 > 72)
[Oct  5 15:45:47] NOTICE[3392]: udptl.c:1010 ast_udptl_write: UDPTL
Transmission error to 216.166.168.17:49154: Message too long 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-10-05 16:49 globalnetinc   Note Added: 0111879                          
======================================================================




More information about the asterisk-bugs mailing list