<span style="font-family: Arial, Helvetica, sans-serif; font-size: 10pt"><span style="font-family: tahoma,arial,sans-serif; font-size: 10pt;"><hr width="100%" size="2" align="center" />
<b>From</b>: "Kevin P. Fleming" <kpfleming@digium.com><br />
<b>Sent</b>: Wednesday, January 26, 2011 2:29 PM<br />
<b>To</b>: asterisk-users@lists.digium.com<br />
<b>Subject</b>: Re: [asterisk-users] res_fax</span><br />
<br />
On 01/26/2011 01:19 PM, Bryant Zimmerman wrote:<br />
><br />
> ------------------------------------------------------------------------<br />
> *From*: "Kevin P. Fleming" <kpfleming@digium.com><br />
> *Sent*: Wednesday, January 26, 2011 1:50 PM<br />
> *To*: asterisk-users@lists.digium.com<br />
> *Subject*: Re: [asterisk-users] res_fax<br />
><br />
> On 01/26/2011 12:42 PM, Bryant Zimmerman wrote:<br />
>> Steve<br />
>><br />
>> Are there any undocumented options available with ReceiveFAX and the<br />
>> res_fax_spandsp module.<br />
>> I am having issues with getting t.38 to negotiate with Level 3 faxes but<br />
>> if I force t.30 the fax comes in. But the fax does not fall back t.30 if<br />
>> the t.38 fails<br />
><br />
> You haven't posted any logs of the failing attempts, or packet captures<br />
> of the SIP traffic, so it's pretty much impossible for anyone to help<br />
> you debug this (anyone who tried would just be guessing).<br />
><br />
> Steve did not write res_fax (which where SendFAX and ReceiveFAX come<br />
> from), and there are no 'undocumented' options available for it, because<br />
> it's open source and the source code shows all the options that are<br />
> available.<br />
><br />
> If you would like to try to figure out what is going on, start by<br />
> posting a *complete* log file from Asterisk for a failed inbound FAX<br />
> attempt, with 'core set debug 10' and 'core set verbose 10' and all<br />
> logger levels (including 'fax') enabled.<br />
><br />
> ----------------------------------------------------------------------<br />
><br />
> Kevin<br />
><br />
> These were attached to another post. Here are the links again<br />
> Fax Debug.txt<br />
> <http://webmail.zktech.com/public/downloadfile.aspx?f=KERoF6PWf6e2FK8S5zgEDs02rFGdd7zE0AIG7tjbCR9a06oFY1NwFap58zDWva3BcdOp%2b%2f%2fuBo8%3d><br />
> cap-t38.pcap<br />
> <http://webmail.zktech.com/public/downloadfile.aspx?f=ulHIhepag5qoKm0cTUmljmT%2f7YCcOPvzlyZcnZg%2fG2B25W%2fsSr6Uwbu%2bET3kbKw84pTJjtuqrPQ%3d><br />
<br />
Unfortunately that log capture is incomplete; it doesn't include any of <br />
the messages that res_fax emits as it goes through T.38 negotiations. <br />
Please ensure that your 'console' channel in logger.conf has <br />
'debug,verbose,warning,notice,error,fax' enabled and that you have 'core <br />
set verbose 10' and 'core set debug 10' set before the call attempt <br />
begins (or at least before ReceiveFAX is executed). If the server is <br />
only processing this particular call, then 'sip set debug on' would also <br />
be helpful.<br />
<br />
-------------------------------------------------------------------------<br />
<br />
Kevin I will get the additional debugs done when there is no other load on the fax. <br />
<br />
Is there a way for me to force t.38 off for a call but to allow t.38 for other calls. What I am thinking is if a t.38 fails to flag the next call from that number to g711 audio. This would at least let me work arround the issue for now where t.38 fails with some endpoints but not others and the g711 audio will work. The issue I am seeing is it appears that with some endpoinds on Level 3 that the t.38 tunnel comes up fine but no fax data starts flowing but this only is happening with faxes coming from some Cisco gateways sending out via PRI using t.30<br />
<br />
Thanks<br />
Bryant<br /></span>