On 02/15/2010 08:57 PM, Vinícius Fontes wrote:
>> ----- "Kevin P. Fleming"<kpflem...@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"<vinic...@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
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
