[asterisk-bugs] [Asterisk 0015649]: T38 Faxing failing on 1.6.1 svn

Asterisk Bug Tracker noreply at bugs.digium.com
Thu Aug 6 13:21:00 CDT 2009


A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=15649 
====================================================================== 
Reported By:                dazza76
Assigned To:                kpfleming
====================================================================== 
Project:                    Asterisk
Issue ID:                   15649
Category:                   Core/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     assigned
Asterisk Version:           1.6.1.1 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): 1.6.1 
SVN Revision (number only!): 209900 
Request Review:              
====================================================================== 
Date Submitted:             2009-08-04 06:28 CDT
Last Modified:              2009-08-06 13:21 CDT
====================================================================== 
Summary:                    T38 Faxing failing on 1.6.1 svn
Description: 
I am attempting to send faxes via t.38 through 2 asterisk servers
i.e
patton -> asterisk 1.6.1 -> asterisk 1.6.1 -> carrier 
what i have noticed is the fax negotiates but no data seems to make it,

when watching the console the below lines appear 
this does not happen on 1.6.1.1 or 1.6.1.2 but does happen on the svn rev
209900
 
the reason for the upgrade is the due to a segfault of ulaw fallback  on 1
carrier i.e issue 15290
Please let me know what log files are required.
====================================================================== 

---------------------------------------------------------------------- 
 (0108730) kpfleming (administrator) - 2009-08-06 13:21
 https://issues.asterisk.org/view.php?id=15649#c108730 
---------------------------------------------------------------------- 
The pcap file seems to be incomplete, as I don't see any of the packets
that arrived from the carrier IP (125.x.x.x), only packets to it.
Regardless, I can tell from the console log that the carrier's gateway told
us we can't send it a T.38 datagram more than 72 bytes in size
(T38FaxMaxDatagram), but that it wants us to use UDP redundancy (sending
copies of the last three frames) when we sent T.38 IFP frames to it.
Combining these two means we can only send *very* small IFP frames, in fact
the limit is so low that spandsp and our UDPTL stack cannot cope with it.
In this case, spandsp generated an IFP frame of 53 bytes (a very reasonable
and safe size), but we couldn't send it because adding redundancy would
mean it went well over the 72 byte limit imposed by the other end.

This is currently a subject of discussion in the SIP Forum FoIP working
group, about how this particular session parameter is not well defined, and
implementations tend to treat it in very different ways. You seem to have
found a particularly bizarre implementation. I'll try to come up with a
workaround and post here when it's available. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-08-06 13:21 kpfleming      Note Added: 0108730                          
======================================================================




More information about the asterisk-bugs mailing list