[Home]

Summary:ASTERISK-14525: SendFAX not working with T.38
Reporter:chrisde (chrisde)Labels:
Date Opened:2009-07-24 12:51:16Date Closed:2011-06-07 14:00:34
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/app_fax
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) call1.txt
( 1) call2.txt
( 2) call3.txt
( 3) call4-newrevision.txt
( 4) call5-newrevision.txt
( 5) call6-newrevision.txt
Description:After several trials with SendFAX and several fax machines it gives me the impression that it does not work at all.
With one fax e.g. I get the info

[Jul 24 15:36:38] WARNING[11293]: app_fax.c:178 phase_e_handler: Error transmitting fax. result=48: Disconnected after permitted retries.
[Jul 24 15:36:38] WARNING[11293]: app_fax.c:680 transmit: Transmission failed

after exchanging some UDPTL packets.
Another fax machine results in

[Jul 24 15:15:55] WARNING[11184]: app_fax.c:128 span_message: WARNING T.30 t30_non_ecm_get_chunk in bad state 3
...
[Jul 24 15:15:57] WARNING[11184]: app_fax.c:178 phase_e_handler: Error transmitting fax. result=13: Unexpected message received.
[Jul 24 15:15:57] WARNING[11184]: app_fax.c:680 transmit: Transmission failed

this is always the same with this fax machine not only sometimes

with another fax machine there seems not to be t.38 at all. after connecting with g711 it only sais

stars24*CLI>
<--- SIP read from UDP://213.148.136.2:5060 --->
hello
<------------->

several times and then it tells

[Jul 24 15:13:43] WARNING[11081]: app_fax.c:178 phase_e_handler: Error transmitting fax. result=49: The call dropped prematurely.
[Jul 24 15:13:43] WARNING[11081]: app_fax.c:677 transmit: Transmission error

always. Not only one time out of 10. I also have to say that all of the calls are terminated with German QSC who support T.38. And the reportet results are just different fax machines that where called with the same sip account at QSC.


****** ADDITIONAL INFORMATION ******

I tried several versions of asterisk (1.6.0.10, 1.6.0.11-rc1, svn version 208502) and followed the installation instructions of spandsp (e.g. to use tifflib 3.8.2). I also tried the stable 0.0.5 version of spandsp and now the latest 0.0.6pre12.
Comments:By: Kevin P. Fleming (kpfleming) 2009-07-24 17:13:37

There have been major changes committed to the 1.6.x branches related to T.38 support this week; I would appreciate you retesting with an up-to-date checkout of the 1.6.0 branch (208742 or later). Thanks!
By: chrisde (chrisde) 2009-07-25 05:41:29

the version had been from yesterday, but I updated again:
Updated to revision 559.
Updated to revision 208812.

but its again almost the same. I attach new sip debug logs. It also looks like there are packets not reaching their destination now... So even worse, not better.
By: Kevin P. Fleming (kpfleming) 2009-07-27 11:15:32

I don't see how this is a problem with Asterisk's T.38 support or with app_fax at all. In both call4 and call6, the Huawei switch sent a reinvite requesting that we switch to T.38, and Asterisk responded with '200 OK' with a proper T.38 answer that matches the offer in the INVITE. However, the Huawei switch never ACKs the '200 OK', and eventually Asterisk times out and hangs up the call because that ACK is critical for proper SIP transaction handling.

I'm going to close this issue; if you can determine that something Asterisk is doing is the reason *why* the Huawei switch is not ACKing the response, feel free to open an issue against chan_sip with the required information.