[asterisk-users] Problems receiving some faxes in T.38

[Steve Underwood]

Hi Santiago,

Santiago Gimeno wrote:
> Hello,
>
> We have been working with the ReceiveFax application for some weeks 
> now in order to receive faxes in T.38 and it works fairly well, but 
> there are some faxes that for some reason we are not able to receive 
> correctly.
>
> The asterisk version we are using is 1.6.0.6 with spandsp-0.0.5pre4 
> and the asterisk machine is behind a CISCO mediaGW to be able to 
> communicate with the PSTN.
>
>
> The SIP call flows are different between the faxes we receive 
> correctly and the ones that fail.
>
> In the case of successfully received faxes, after establishing the 
> audio session between de CISCO and Asterisk, CISCO sends a re-INVITE 
> with the T.38 SDP. The T.38 setup succeeds.
>
> CISCO        Asterisk
>          |              |
>          |              |
>          |              |
>          |INVITE (SDP alaw)
>          |------------->|
>          |200 OK (SDP alaw)
>          |<-------------|
>          |ACK           |
>          |------------->|
>          |Re-INVITE (SDP T.38)
>          |------------->|
>          |200 OK (SDP T.38)
>          |<-------------|
>          |ACK           |
>          |------------->|
>          |              |
>          |..............|
>          |T.38          |
>          |..............|
>          |[t.38]no signal
>          |<-------------|
>          |[t.38]no signal
>          |------------->|
>          |[t.38]CED     |
>          |<-------------|
>          |[t.38]V21-preamble
>          |------------->|
Did you draw that arrow in the wrong direction? The side answering the 
call should send the first V.21 signal.
>          |              |
>          |              |
>
> On the other hand, with some faxes, the re-INVITE is sent by Asterisk 
> and it looks that there is something wrong in the T.38 setup that 
> makes the fax reception fail after the permitted retries. The FAXERROR 
> variable is set to: "Disconnected after permitted retries".
> What I can see from the traces is that it gets to a point that 
> asterisk is sending T.38 data to the CISCO but the CISCO doesn't answer.
>
>
> CISCO        Asterisk
>           |              |
>           |              |
>           |              |
>           |INVITE (SDP alaw)
>           |------------->|
>           |200 OK (SDP alaw)
>           |<-------------|
>           |ACK           |
>           |------------->|
>           |Re-INVITE (SDP T.38)
>           |<-------------|
>           |200 OK (SDP T.38)
>           |------------->|
>           |ACK           |
>           |<-------------|
>           |              |
>           |..............|
>           |T.38          |
>           |..............|
>           |[t.38]no signal
>           |<-------------|
>           |[t.38]no signal
>           |------------->|
>           |[t.38]CED     |
>           |<-------------|
>           |[t.38]no signal
>           |------------->|
>           |[t.38]V21-preamble
>           |<-------------|
>           |[t.38]hdlc    |
>           |<-------------|
>           |[t.38]no signal
>           |<-------------|
>           |[t.38]V21-preamble
>           |<-------------|
>           |[t.38]hdlc    |
>           |<-------------|
>           |[t.38]no signal
>           |<-------------|
>           |[t.38]V21-preamble
>           |<-------------|
>           |[t.38]hdlc    |
>           |<-------------|
>           |[t.38]no signal
>           |<-------------|
>           |[t.38]V21-preamble
>           |<-------------|
>           |[t.38]hdlc    |
>           |<-------------|
>           |[t.38]no signal
>           |<-------------|
>           |[t.38]V21-preamble
>           |<-------------|
>           |[t.38]DCN     |
>           |<-------------|
>           |BYE           |
>           |<-------------|
>           |200 OK        |
>           |------------->|
>
>
> Any idea of what might be happening?
>
> Thanks in advance. Best regards,
>
> Santiago Gimeno
>
>
>
>
> The relevant information in the asterisk configuration files is:
>
> extensions.conf
>
> [fax-in]
> exten => 99999,1,Set(INCOMING_FAXFILE=/root/santi/fax/incoming.tif)
> exten => 99999,n,Answer()
> exten => 99999,n,Wait(3)
> exten => 99999,n,ReceiveFax(${INCOMING_FAXFILE})
Try changing that Wait(3) to Wait(6). It seems some T.38 boxes act 
strangely if the T.38 negotiation occurs too soon after the call starts. 
I am not clear why, though I have tried to find suitable test cases to 
pin this down.
>
> sip.conf
>
> [general]
> canreinvite=no
> t38pt_udptl=yes
> disallow=all
> allow=alaw
>
> context=fax-in
>
>
> The CISCO peer configuration:
>
> dial-peer voice 6 voip
> destination-pattern 88T
> session protocol sipv2
> session target ipv4:10.100.0.51
> session transport udp
> dtmf-relay rtp-nte
> codec g711alaw
> fax-relay ecm disable
Why turn off ECM?
> fax nsf 000000
> fax protocol t38 ls-redundancy 5 hs-redundancy 2 fallback none
> no vad
Regards,
Steve