[asterisk-users] Still on spandsp/app_fax and T.38

[Steve Underwood]

On 02/15/2010 08:57 PM, Vinícius Fontes wrote:
>> ----- "Kevin P. Fleming"<kpfleming at digium.com>  escreveu:
>>
>>      
>>> Vinícius Fontes wrote:
>>>        
>>>> Will do. You guys will have my feedback on monday. If everything
>>>>          
>>> goes okay with that change, I'll post a patch on Mantis.
>>>
>>> No need for the patch; it's already on my radar, and if you confirm
>>> that
>>>   it actually solves an interop problem, I'll commit the update to
>>>        
>> the
>>      
>>> various branches it belongs in. I'd still like to hear from Steve
>>> Underwood if I misinterpreted the MMR/JBIG transcoding function
>>>        
>> calls
>>      
>>> in
>>>   spandsp that led me to enabling these features in the first
>>>        
>> place...
>>      
>>>        
> ----- "Vinícius Fontes"<vinicius at canall.com.br>  escreveu:
>
>    
>> Unfortunely it didn't solve the problem. Here's the session packet
>> capture after editing app_fax.c.
>> http://www.canall.com.br/wireshark_t38_jbig.gz
>>
>>      
> I've tried everything. EVERYTHING. Almost every combination of maxdatagram sizes, error correction modes, hacking app_fax.c to limit the baudrate to 9600... nothing. Every single time I get rates like 2400, 4800 or if I'm very lucky, 7200.
>
> In ALL cases, *every single time*, FFA negotiated the connection at 9600bps and the fax was received cleanly.
>
> It's clear to me that the provider should not be blamed on this case. I tried using a Linksys SPA8000 and faxes are also received perfectly. Something, either in Asterisk, SpanDSP or app_fax is just not right.
>
> For now I'll have to stick with FFA for my company and my customers. They will not be happy to know that in order to transmit or receive more than one fax simultaneously they will need a US$40 license, but it's still better than quadrupling the phone bills because for some unknown reason the baudrate is 4 times slower than it should be.
>
> I'm still willing to solve this. I really want to get app_fax working as intended. I'm sure this is on the best interests of the community as well. Unfortunely I don't have the knowledge or skills on faxing protocols, DSP and C development or else I would have solved this myself. But I'm doing my part on this by providing all necessary info and running every single test I'm asked to.
>
> IMHO it would be a shame if we need to rely on a commercial piece of software because the open source equivalent is 4 times slower on some cases. For me it defies the very reason of Asterisk's existence: an open source alternative on a market flooded with proprietary solutions.
>
>    
I've been travelling for the last week, so I only just got back to this 
problem.

Let's be clear. The problem is a broken T.38 gateway at the far end. For 
some reason your other tests are not provoking the same bad behaviour. I 
have seen similar behaviour in a log before, but I was unable to follow 
up that time, and find what was really going on. A lot of the work in 
implementing T.38 is making it tolerant of other broken T.38 
implementations. Let's see what we can do about this one.

It looks like the T.38 gateway at the far end does something very wrong 
3.5s after the end of the DIS and FTT messages from app_fax end. 3.5s is 
one of the key timeouts in the T.30 protocol, so I expect the gateway is 
confused, and is trying to incorrectly spoof the T.38 protocol. 3.5s 
after the DIS message ends, the far end FAX machine is sending TCF data, 
which suddenly corrupts. Even in the successful FFA packet trace I was 
given, there is minor corruption at the same point. Its not enough to 
upset transmission, though. With app_fax the TCF transmission is totally 
messed up. My guess is the far end gateway suddenly starts transmitting 
V.21 data to the FAX machine, even though it is already successfully 
decoding V.29 data from that FAX machine. I have seen other T.38 
gateways start sending at an entirely wrong time. So, let's list the 
differences. The options offered in the DIS messages from FFA and 
app_fax are very similar. The timing of the messages is also very 
similar. The differences are:

     - app_fax is not sending an identity (CSI) frame, but FFA is.
     - FFA sends many no-signal packets, while app_fax only sends one. 
Either should be OK, and you'll see both practices used by various T.38 
implementations.
     - FFA sends many v21-preamble and v29-9600-training packets, while 
app_fax only sends one. Again, either should be OK, and both are common 
practices.

You could try defining the same identity string for app_fax that you 
have defined for FFA. Trying to make the other things more similar would 
require additional work. Maybe you should try that change first, as it 
is very simple, and requires no code changes.

FFA sends its repeating no-signal and preamble packets with incrementing 
sequence numbers. While its not the only system which does that, it 
confuses some T.38 implementations. The T.38 spec is too vague to say 
whether the practice is right or wrong. In other applications of the FAX 
machine in spandsp, the software has been set up to send multiple copies 
on the key packets, with the same sequence number for all the copies. 
This seems to be the most compatible way to send these repeats. I don't 
know if the UDPTL infrastructure in Asterisk can do that.

I also notice that FFA sends a no-signal message immediately after 
sending the last of the control or image data. A *lot* of T.38 
implementations have problems with that. They drop their modem signal 
immediately, although they still have some data in their transmission 
buffer. The control messages usually get through OK, but the end of each 
page can be corrupted. There is nothing wrong with what FFA is doing, 
according to the T.38 spec. It just isn't very tolerant of all those 
broken T.38 implementations out there.

Regards,
Steve