> > ----- "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. -- _____________________________________________________________________ -- 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
