[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