[Home]

Summary:ASTERISK-15883: 1.6.1.18 -> 1.6.2.6 T38 Fax: call drops
Reporter:Sean Darcy (seandarcy)Labels:
Date Opened:2010-03-27 16:27:20Date Closed:2011-07-26 15:25:32
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/app_fax
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) error.sip.fax.edit
( 1) sip-fax-error.20100501
Description:Using spandsp-0.0.6-pre17, SendFax on 1.6.1.18 and ReceiveFax on
1.6.2.8. Sip.conf on both sides has t38pt_udptl = yes.

    -- Executing [s@fax-tx-test:3] SendFAX("SIP/side-sip-00000009",
"/var/spool/asterisk/fax/20091113_1455.tif") in new stack
[Mar 20 17:05:34] WARNING[6433]: app_fax.c:178 phase_e_handler: Error
transmitting fax. result=49: The call dropped prematurely.
[Mar 20 17:05:34] WARNING[6433]: app_fax.c:772 transmit: Transmission failed
    -- Executing [s@fax-tx-test:4] Hangup("SIP/side-sip-00000009", "")
in new stack
  == Spawn extension (fax-tx-test, s, 4) exited non-zero on
'SIP/side-sip-00000009'
    -- Executing [h@fax-tx-test:1] NoOp("SIP/side-sip-00000009",
"FAXSTATUS: FAILED
FAXERROR: The call dropped prematurely
FAXMODE: T38")

On the receive side:

    -- Executing [s@incoming-fax:2] ReceiveFAX("SIP/side-sip-00000002",
"/var/spool/asterisk/fax/20100320_1705.tif") in new stack
[Mar 20 17:05:34] WARNING[21512]: app_fax.c:223 phase_e_handler: Error
transmitting fax. result=48: Disconnected after permitted retries.
[Mar 20 17:05:34] WARNING[21512]: app_fax.c:820 transmit: Transmission
failed
    -- Executing [s@incoming-fax:3] Hangup("SIP/side-sip-00000002", "")
in new stack

FAXSTATUS: FAILED
FAXERROR: Disconnected after permitted retries
FAXMODE: T38")

Sip audio calls work fine over side-sip.

And if I use the same script to send DAHDI->DAHDI over pstn, it works.

I'm uploading error.sip.fax, a sip debug from the SendFax end. 10.10.10.180 is 1.6.1.18 SendFax, 64.aaa.bbb.ccc is the SendFax public ip. 10.10.11.180 is 1.6.2.6 ReceiveFax and 76.xxx.yyy.zzz is the ReceiveFax public ip.
Comments:By: John Todd (jtodd) 2010-04-27 13:29:51

I'm not sure when we'll be able to get to this, since it seems to be within the spandsp code.  Hopefully someone else who is more familiar with that code can take a shot at fixing this.  Perhaps you can reach out on the mailing list?

To determine if this is something with spandsp or somewhere higher in the stack, perhaps you might try loading up the free single-channel version of the Digium fax driver and see if you can make it work.  If it still fails, you'll get a lot more attention from Digium developers since that's a "commercial" module.
By: Elazar Broad (ebroad) 2010-04-28 09:24:53

<snip>
a=T38FaxMaxDatagram:1400
</snip>

1400 is a bit high, try setting maxdatagram to something smaller, i.e.
t38pt_udptl = yes,fec,maxdatagram=200
in your sip.conf.
By: Sean Darcy (seandarcy) 2010-05-02 13:42:49

Upgraded to 1.6.2.7-rc3 on both boxes. spandsp-pre17 and 20100501.

Posted to spandsp list:

http://soft-switch.org/pipermail/spandsp/2010-May/000076.html

Hi Sean,

It looks like the two parties are not communicating. Think is a problem
outside spandsp. You should address it to the Asterisk users mailing list.

Stve

Tried t38pt_udptl = yes,fec,maxdatagram=200 in both boxes. No joy. I've attached the DEBUG from the receive side. Setting maxdatagram seems to make no difference:

[May  2 14:21:20] DEBUG[25914]: chan_sip.c:8940 process_sdp_a_image: FaxMaxDatagram: 1400
[May  2 14:21:20] DEBUG[25914]: chan_sip.c:8355 process_sdp: Processing media-level (image) SDP a=T38FaxMaxDatagram:1400... OK.

In the attached DEBUG all messages are from chan_sip.c and app_fax.c. Sure looks like app_fax just can't make the connection.

I've tried to build the new asterisk fax driver, but it won't build on 1.6.2. The commercial is only for i386, not x86-64.
By: Marek Cervenka (cervajs) 2010-05-17 11:11:54

i have the same problem with app_fax and spandsp
By: Antoine Reversat (areversat) 2010-06-02 13:58:13

What's weird is that that in app_fax.c it says :

       /* If we are switching to T38, remove phase E handler. Otherwise it will be executed
          by t30_terminate, display diagnostics and set status variables although no transmittion
          has taken place yet. */

So, if my understanding is correct when we are in t.38 we don't use phase_e_handler and should therefore never reach those error messages.

I have the same problem using 1.6.2.7 here.
By: Antoine Reversat (areversat) 2010-06-02 15:04:21

Ok after having a look at sip-fax-error.20100501 it seems that the error message is actually legitimate since it tries phase B several times (phase B is where the negotiating of things like tranmission rate, etc takes place) and it fails, so it it gives up :

[May  2 14:21:40] DEBUG[27971]: app_fax.c:175 span_message: FLOW T.30 T4 expired in phase T30_PHASE_B_RX, state 17
[May  2 14:21:40] DEBUG[27971]: app_fax.c:175 span_message: FLOW T.30 Too many retries. Giving up.

I don't know if it is a problem with the configuration of the fax machine or something else but it doesn't seem to be a bug in asterisk per say.
By: Sean Darcy (seandarcy) 2010-06-06 19:11:37

But the issue here is asterisk -> asterisk. That is we are faxing from asterisk to asterisk. So if it fails, it's got to be asterisk.
By: Leif Madsen (lmadsen) 2011-07-26 15:25:04.367-0500

Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.4 and 1.6.x branches has ended. For continued maintenance support please move to the 1.8 branch which is a long term support (LTS) branch. For more information about branch support, please see https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions

If this is still an issue, please open a new issue so it can be re-triaged appropriately. Thanks!