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

[Steve Underwood]

Santiago Gimeno wrote:
> Hi Steve,
>
> Thanks for the answers.
>
> Comments inline.
>
> 2009/5/20 Steve Underwood <steveu at coppice.org>:
>
>   
>> Did you draw that arrow in the wrong direction? The side answering the
>> call should send the first V.21 signal.
>>     
>
> No. That's what the wireshark trace shows.
>   
Strange.
>   
>>> 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.
>>     
>
> Changed that, but no luck, same problem.
>
> What it is strange to me is that receiving faxes always work for me in
> the case that the calling part (CISCO) sends the re-INVITE but it
> doesn't if its the receiver of the fax (asterisk) that sends this
> re-INVITE. I thought the standard said that the re-INVITE should be
> sent by the receiver ot the fax.
>   
The T.38 spec says the receiving side should initiate the re-invite, but 
its really common for it to be a free-for-all with calls often falling 
over when both ends re-invite at the same moment.
> This is part of the log file with debug level set to 4 showing the
> start of the T.38 negotiation. The setup is tried 4 times before
> dropping the call. I hope this helps to shed some light on the issue.
>   
Not really. It just shows very little comming back from the Cisco. Can 
you get a packet trace from a good call and a bad one, and e-mail them 
to me? It doesn't look like this has anything to do with spandsp. It 
looks likes its something in the call negotiation going wrong. I'm still 
interested in taking a look, though.

Steve