[Home]

Summary:ASTERISK-15352: [patch] [regression] T.38 no longer functions
Reporter:Scott Johnson (globalnetinc)Labels:
Date Opened:2009-12-21 19:59:48.000-0600Date Closed:2010-03-17 09:34:52
Priority:MajorRegression?Yes
Status:Closed/CompleteComponents:Channels/chan_sip/T.38
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 1.6.11.debug.sav
( 1) debug.sav
( 2) debug.v2
( 3) debug-sip.sav
( 4) t38_udptl_ifp_debug1.diff
( 5) t38_udptl_ifp_debug2.diff
( 6) udptl-max-ifp-fix1.diff
Description:After upgrade from 1.6.11 to 1.6.1.12 T.38 no longer functions.

WARNING[26670] udptl.c: (SIP/4065877430): UDPTL asked to send 1 bytes of IFP when far end only prepared to accept 0 bytes; data loss will occur.You may need to override the T38FaxMaxDatagram value for this endpoint in the channel driver configuration.

This is generated even though sip.conf has
t38pt_udptl=yes,redundancy,maxdatagram=176

After returning to 1.6.1.11 T.38 functions correctly.
Comments:By: Scott Johnson (globalnetinc) 2009-12-22 16:16:32.000-0600

Just as an FYI it does not work in 1.6.2.0 either.  Same issue.  I am sure it is common code.
By: Scott Johnson (globalnetinc) 2010-01-08 10:56:02.000-0600

Seems T.38 should be more important than to leave broke for 2 versions.
By: Sergey Tamkovich (sergee) 2010-01-11 06:44:25.000-0600

globalnetinc, did you try to increase maxdatagram?
i'm working on 1.6.0 with t38pt_udptl=yes,redundancy,maxdatagram=400 - everything works fine.
By: Scott Johnson (globalnetinc) 2010-01-11 11:47:48.000-0600

Please read the info.  

t38pt_udptl=yes,redundancy,maxdatagram=176

yet the error reports UDPTL asked to send 1 bytes of IFP when far end only prepared to accept 0 bytes; data loss will occur.You may need to override the T38FaxMaxDatagram value for this endpoint in the channel driver configuration.

If it was reading the SDP or the the maxdatagram correctly it would have at least 176 in the value not zero.  If the version is returned to 1.6.1.11 it faxes and does read the value.  Just setting to 400 makes no difference nor should you be doing it unless both ends can accept that as a packet.  In my case the largest packet that the SIP provider will accept is 176.  9600 baud with redundancy and a redundancy value of 1
By: Matthew Nicholson (mnicholson) 2010-01-11 16:14:12.000-0600

I suspect something is causing the max ifp size to not be set properly in your case.  Please test with the patch I uploaded and debug level set to 1 and upload a debug log from your test.
By: Scott Johnson (globalnetinc) 2010-01-11 21:07:59.000-0600

patch was applied and the files is now uploaded.
By: Scott Johnson (globalnetinc) 2010-01-11 22:49:34.000-0600

I have also uploaded one with sip debug.
By: Scott Johnson (globalnetinc) 2010-01-11 23:07:23.000-0600

I also uploaded the debug from the working version of 1.6.1.11
By: Matthew Nicholson (mnicholson) 2010-01-12 09:54:59.000-0600

Please test again with the new patch I uploaded and upload the resulting debug log.
By: Scott Johnson (globalnetinc) 2010-01-12 15:01:42.000-0600

It is ready I will get it done tonight when customers are not using the server.
By: Scott Johnson (globalnetinc) 2010-01-13 01:08:48.000-0600

File is uploaded
By: Matthew Nicholson (mnicholson) 2010-01-13 11:26:22.000-0600

Thanks for testing.  Something is causing your max ifp value to get set to 0.  I will investigate this further.  I may have another patch for you to test with tonight.
By: Scott Johnson (globalnetinc) 2010-01-13 13:41:03.000-0600

Thanks.  I can test anything late at night.
By: Matthew Nicholson (mnicholson) 2010-01-13 16:38:58.000-0600

Ok, test the patch I just uploaded.  It should fix the issue.  It also contains the debugging code I gave you previously, so if it does not work, upload another debug trace.
By: Scott Johnson (globalnetinc) 2010-01-13 18:16:59.000-0600

Mind telling me what you think the issue is?
By: Scott Johnson (globalnetinc) 2010-01-13 20:30:18.000-0600

Yep, you got it.  version 1.6.1.12 now sends faxes.
By: Scott Johnson (globalnetinc) 2010-01-14 09:46:31.000-0600

patch also works with 1.6.2.0 and now both can fax.
By: Digium Subversion (svnbot) 2010-01-14 10:17:50.000-0600

Repository: asterisk
Revision: 240078

U   trunk/main/udptl.c

------------------------------------------------------------------------
r240078 | mnicholson | 2010-01-14 10:14:35 -0600 (Thu, 14 Jan 2010) | 9 lines

This change fixes a few bugs in the way the far max IFP was calculated that were introduced in r231692.

(closes issue ASTERISK-15352)
Reported by: globalnetinc
Patches:
     udptl-max-ifp-fix1.diff uploaded by mnicholson (license 96)
Tested by: globalnetinc


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

http://svn.digium.com/view/asterisk?view=rev&revision=240078
By: Digium Subversion (svnbot) 2010-01-14 10:18:44.000-0600

Repository: asterisk
Revision: 240079

_U  branches/1.6.2/
U   branches/1.6.2/main/udptl.c

------------------------------------------------------------------------
r240079 | mnicholson | 2010-01-14 10:15:47 -0600 (Thu, 14 Jan 2010) | 15 lines

Merged revisions 240078 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r240078 | mnicholson | 2010-01-14 10:14:35 -0600 (Thu, 14 Jan 2010) | 2 lines
 
 This change fixes a few bugs in the way the far max IFP was calculated that were introduced in r231692.

 (closes issue ASTERISK-15352)
 Reported by: globalnetinc
 Patches:
       udptl-max-ifp-fix1.diff uploaded by mnicholson (license 96)
 Tested by: globalnetinc
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=240079
By: Digium Subversion (svnbot) 2010-01-14 10:19:16.000-0600

Repository: asterisk
Revision: 240089

_U  branches/1.6.1/
U   branches/1.6.1/main/udptl.c

------------------------------------------------------------------------
r240089 | mnicholson | 2010-01-14 10:19:15 -0600 (Thu, 14 Jan 2010) | 15 lines

Merged revisions 240078 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r240078 | mnicholson | 2010-01-14 10:14:35 -0600 (Thu, 14 Jan 2010) | 9 lines
 
 This change fixes a few bugs in the way the far max IFP was calculated that were introduced in r231692.
 
 (closes issue ASTERISK-15352)
 Reported by: globalnetinc
 Patches:
       udptl-max-ifp-fix1.diff uploaded by mnicholson (license 96)
 Tested by: globalnetinc
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=240089
By: Digium Subversion (svnbot) 2010-01-14 10:19:42.000-0600

Repository: asterisk
Revision: 240092

_U  branches/1.6.0/
U   branches/1.6.0/main/udptl.c

------------------------------------------------------------------------
r240092 | mnicholson | 2010-01-14 10:19:42 -0600 (Thu, 14 Jan 2010) | 15 lines

Merged revisions 240078 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r240078 | mnicholson | 2010-01-14 10:14:35 -0600 (Thu, 14 Jan 2010) | 9 lines
 
 This change fixes a few bugs in the way the far max IFP was calculated that were introduced in r231692.
 
 (closes issue ASTERISK-15352)
 Reported by: globalnetinc
 Patches:
       udptl-max-ifp-fix1.diff uploaded by mnicholson (license 96)
 Tested by: globalnetinc
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=240092
By: Scott Johnson (globalnetinc) 2010-02-11 00:40:25.000-0600

I do not see this fix mentioned in 1.6.2.3-rc2 or 1.6.1.15-rc2