Thanks Steve. Do you think this might have been causing 'missing' parts from some faxes I was sending via TxFAX? I've had problems with missing parts of faxes sent out via TxFAX... An example of which is here:
http://gravsol.com/corruptfax.pdf Interestingly, faxes which have little content (mostly whitespace on the page) often seem to go through okay, but 'busy' faxes with lots of content have problems with whole lines missing... Although it always seems to be the same parts of the page that are missing and the top bit of the page seems to go through okay - which makes me think it's a problem with the encoding/decoding of T.30 between TxFAX and the destination fax machine? Are there known issues with SpanDSP/TxFAX and certain fax machines - and is this buggy T.30 implementations on many fax machines do you think? The machines I have had problems with are mostly Brother machines (2850, MFC-9600 etc.) Interestingly *inbound* fax from these problem machines (via RxFAX works flawlessly!) Are there any parameters in the T.30 encoding of SpanDSP I can tweak - or am I barking up the wrong tree? Any advice you could offer would be great... Steve Underwood wrote: >Hi, > >Someone reported that the T.38 code in OpenPBX was no better on a lossy >link with redundancy enabled than without. I found a feature missing >from the code which should have been there since OpenPBX first started. >This means any missing packets recovered from redundant information were >being thrown away, probably with some memory leakage. I wonder how that >happened? Anyway, I put the missing code back, and I hope T.38 will be >more robust now. > >Regards, >Steve > >_______________________________________________ >Openpbx-users mailing list >[EMAIL PROTECTED] >http://lists.openpbx.org/mailman/listinfo/openpbx-users > > _______________________________________________ Openpbx-users mailing list [EMAIL PROTECTED] http://lists.openpbx.org/mailman/listinfo/openpbx-users
