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

[Steve Underwood]

Hi Vinícius,

Comparing the successful log using FFA and the failing one using 
app_fax, I see the following:

In the call using FFA, the far end system sends a V.29/9600bps FAX page, 
using T.38, which transfers cleanly, and the call ends.

In the call using app_fax/spandsp, the SIP has a couple of key 
difference. Asterisk incorrectly adds

T38FaxTranscodingMMR
T38FaxTranscodingJBIG

to the SDP. I don't know if that might be confusing the far end. The 
T.38 exchange starts in a very similar way to the FFA call, up to the 
middle of the TCF data. This should be all zeros, but half way through 
the far end suddenly starts sending rubbish.

Spandsp correctly rejects this.

The other system sends bad training data at V.27ter/4800bps. Spandsp 
rejects it.

The other system sends clean training data at V.27ter/2400bps. Spandsp 
accepts it.

The other system sends a page at V.27ter/2400bps. Spandsp accepts it.

The only wrongdoing I see is the far end going weird in the training 
data, yet this doesn't happen with the FFA call. Whatever makes the far 
end fall over must be something fairly subtle. Since the 2 SDP lines I 
listed above shouldn't be there, I think they should be removed, and the 
test tried again.

Much of the work in developing a robust T.38 implementation is working 
around all the crappy implementations out there.

Steve



On 02/06/2010 01:47 AM, Vinícius Fontes wrote:
> There you go: http://www.canall.com.br/wireshark_trace_t38_ffa.gz
>
>
> Atenciosamente,
>
> Vinícius Fontes
> Gerente de Segurança da Informação
> Canall Tecnologia em Comunicações
> Passo Fundo - RS - Brasil
> +55 54 2104-7000
>
> Information Security Manager
> Canall Tecnologia em Comunicações
> Passo Fundo - RS - Brazil
> +55 54 2104-7000
>
> ----- "Steve Underwood"<steveu at coppice.org>  escreveu:
>
>    
>> Hi Vinícius,
>>
>> Asterisk + Spandsp is working correctly in that call.
>>
>> The other system sends bad training data at V.29/9600bps. Spandsp
>> rejects it.
>> The other system sends bad training data at V.27ter/4800bps. Spandsp
>> rejects it.
>> The other system sends clean training data at V.27ter/2400bps. Spandsp
>>
>> accepts it.
>> The other system sends a page at V.27ter/2400bps. Spandsp accepts it.
>>
>> The bad training data is *really* bad. It should be 1.5s of all zero
>> bits. It starts off with zeros, but after a few hundred milliseconds
>> it
>> changes to complete rubbish. I can't believe the Commetrex engine in
>> Digium's FAX for Asterisk would accept this. Perhaps something subtle
>>
>> means they are sent the correct data. Can you send a wireshark log of
>> a
>> call with FAX for Asterisk?
>>
>> Steve
>>
>>
>> On 02/06/2010 12:43 AM, Vinícius Fontes wrote:
>>      
>>> No problem, hosted it on my company's website:
>>>        
>> http://www.canall.com.br/wireshark_trace_t38.gz.
>>      
>>>
>>> Atenciosamente,
>>>
>>> Vinícius Fontes
>>> Gerente de Segurança da Informação
>>> Canall Tecnologia em Comunicações
>>> Passo Fundo - RS - Brasil
>>> +55 54 2104-7000
>>>
>>> Information Security Manager
>>> Canall Tecnologia em Comunicações
>>> Passo Fundo - RS - Brazil
>>> +55 54 2104-7000
>>>
>>> ----- "Steve Underwood"<steveu at coppice.org>   escreveu:
>>>
>>>
>>>        
>>>> On 02/06/2010 12:01 AM, Vinícius Fontes wrote:
>>>>
>>>>          
>>>>> Here's the packet trace I promised:
>>>>>
>>>>>            
>>>> http://www.zshare.net/download/72186098494e6f8c/.
>>>>
>>>>          
>>>>> As this is a production system, there were a few calls along with
>>>>>
>>>>>            
>>>> the one that interests us. The one you're looking for is that from
>>>> 5433142499 at 10.150.65.16 to 5421047008 at 10.153.66.146. The provider
>>>>          
>> has
>>      
>>>> the address 10.150.65.16 and my box has the address 10.153.66.146.
>>>>
>>>>          
>>>>>
>>>>>            
>>>> Can you put the file somewhere that actually works. I've downloaded
>>>>          
>> it
>>      
>>>> 5
>>>> times now, and it has been cutoff at different points each time.
>>>>          
>> These
>>      
>>>> free file sharing services all seem to do this. Maybe they all run
>>>>          
>> the
>>      
>>>> same broken software.
>>>>
>>>> Steve
>>>>
>>>>          
>>>        
>