[asterisk-users] Re: Spandsp rxfax txtax fails no errors

[daveasterisk]

Thanks for the response!!!
I enabled debuging in the menuselect configuration for compiling 
asterisk 1.4 beta3. In logging.conf enabled debug loggin to the 
/var/log/asterisk/debug file and to the console. Restarted (not just 
reload) asterisk and there is plenty of general debugging info in the 
debug log file. I also am calling the fax apps with debug argument as 
follows
exten => fax,n,rxfax(${FAXFILE}|debug)

and
exten => fax,n,rxfax(${FAXFILE}|debug)

Looking at the code in app_rxfax.c and app_txfax.c there should be 
plenty of information in the debug log on failure or success. However I 
haven't found any debug log information that should be generated. It is 
like it just does a return 0 at the beginning of the application.

I found some documentation on the system() call that says that the dial 
plan will jump to n+101 priority if the return value is not 0.
So I setup the dial plan:
[outgoingfax]
exten => out_fax,1,Wait(2)
exten => out_fax,2,txfax(${TXFAX_NAME}|caller|debug)
exten => out_fax,3,system(echo sent fax file ${TXFAX_NAME} > /tmp/fax.log )
exten => out_fax,4,Hangup
exten => out_fax,103,system(echo failed fax file ${TXFAX_NAME} > 
/tmp/fax.log )
exten => h,1,Hangup()

No /tmp/fax.log file created at all.

asterisk -rdddddddvvvvvvvvvvvvvvvvv

-- Executing [out_fax at outgoingfax:1] Wait("SIP/inettrunk-081e8100", "2") 
in new stack
-- Executing [out_fax at outgoingfax:2] TxFAX("SIP/inettrunk-081e8100", 
"/tmp/test.tif") in new stack
[Nov 29 13:26:13] DEBUG[28613]: pbx_spool.c:391 scan_service: Delaying 
retry since we're currently running '
}+@
}+ at ol/asterisk/outgoing/fax.call'
[Nov 29 13:26:24] DEBUG[28613]: pbx_spool.c:391 scan_service: Delaying 
retry since we're currently running '/var/spool/asterisk/outgoing/fax.call'
[Nov 29 13:26:35] DEBUG[28613]: pbx_spool.c:391 scan_service: Delaying 
retry since we're currently running 'h�,z+ at ol/asterisk/outgoing/fax.call'

 From this it looks like it just gets stuck in the TxFAX app.

Thanks!


> On Tue, Nov 21, 2006 at 03:33:57PM -0800, daveasterisk wrote:
>   
>> > Is there anyone who can help with this?
>> > rxfax and txfax when called in the extensions do nothing and no error 
>> > are generated that I can find.
>>   
>
> I asked something similar on the list a while ago, got no answers and
> took a look at the code myself and learned a little bit. Before
> I used System(tiff2pdf....) to detect errors, which
> wasn't so elegant, but worked well anyway.
>
> The description looks like this:
>
>     *CLI> show application RxFAX 
>       -= Info about application 'RxFAX' =- 
>
>     [Synopsis]
>     Receive a FAX to a file
>
>     [Description]
>       RxFAX(filename[|caller][|debug]): Receives a FAX from the channel into the
>     given filename. If the file exists it will be overwritten. The file
>     should be in TIFF/F format.
>     The "caller" option makes the application behave as a calling machine,
>     rather than the answering machine. The default behaviour is to behave as
>     an answering machine.
>     Uses LOCALSTATIONID to identify itself to the remote end.
> 	 LOCALHEADERINFO to generate a header line on each page.
>     Sets REMOTESTATIONID to the sender CSID.
> 	 FAXPAGES to the number of pages received.
> 	 FAXBITRATE to the transmition rate.
> 	 FAXRESOLUTION to the resolution.
>     Returns -1 when the user hangs up.
>     Returns 0 otherwise.
>
>
> If you read the code, a return value of -1 means error and 0
> means success, although not clearly stated so in the message
> above. So far, that is what you would expect, but return values
> are not testable in * dial plans, as far as I know.
>
> I modified app_rxfax.c to set FAXSTATUS to ERROR or SUCCESS and
> got it working, but then I discovered that the four return variables
> listed above are set only on success. I think that FAXPAGES
> would be the best to use for error checking. But still, you
> will not get a reason for the failure...
>
> There is a line in the code:
>
>         ast_log(LOG_DEBUG, "Fax receive not successful - result (%d) %s.\n", result, t30_completion_code_to_str(result));
>
> that shows us that written information on the type of error *is* available.
> These message are in the spandsp code I suppose.
>
> Regards:                           Håkan