HylaFAX The world's most advanced open source fax server

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [hylafax-users] receiving: logic of RTN negative followed by MPS



Giulio Orsero wrote:

HylaFAX-4.2.5 receiving on class1.

I had a case in which:
- HylaFAX told the remote end: MCF (confirm received OK)
- the received tiff file was corrupt

I think the sender sent 2 pages and HylaFAX put them in 1 page.

Looking at the attached logs you can see:
Sender sends 1st page
Sender sends MPS
HylaFAX rejects 1st page and sends RTN
Sender sends what I think is its 2nd page
HylaFAX confirms with MCF (and receive 1 corrupt page)

So, since sender said MPS and then sent just 1 page after RTN we can assume
sender ignored RTN; however, in this particular case maybe HylaFAX could
have known something was wrong since it received an MPS but in the end it
MCFed with just 1 page on hand?

Since the tiff is corrupt, is there a method to clean it? I tried tiffcp w/o
success.
$ tiffcp -c none fax000011111.tif 1.tif
Fax4Decode: Warning, fax000035905.tif: Line length mismatch at scanline 151
(got 1729, expected 1728).
Fax4Decode: Warning, fax000035905.tif: Line length mismatch at scanline 151
(got 1882, expected 1728).
Fax4Decode: Warning, fax000035905.tif: Line length mismatch at scanline 151
(got 1740, expected 1728).


Part of this issue ... the part about faxgetty saving corrupt image files is discussed here:


http://bugs.hylafax.org/show_bug.cgi?id=707

As for the logic part of the issue... my opinion is that in non-ECM mode HylaFAX should, by default, save all pages, even pages that were RTN'ed. (This was proposed years ago by Vyacheslav when the SaveUnconfirmedPages work was done.) Certainly faxgetty would need to do a better job about cleaning up the TIFF data and ensuring that the data is readable by TIFF viewers.

I've actually tried to code up the save-RTNed-pages feature, but it's a bit messy - the current code doesn't exactly make it a simple task. The code was really designed around the principle of discarding RTN'ed pages.

Now, as far as the logic involved in the fact that faxgetty *should know* there are two pages and not just one... yeah, I think that's very obvious... and this is why I think that it should save all pages, even RTN'ed ones. Most non-ECM senders that get RTN from us will ignore it... meaning pages will be lost on reception. On the other hand, even if we had saved those RTN'ed pages it's quite possible that they were so distorted that they would have been useless anyway. It's one of those things about non-ECM fax protocol ... it just doesn't provide a good mechanism to ensure that each page is delivered. A fax receiver can know if it's one page or more than one page if it sees MPS... but without examining the actual TIFF data and reading comparing it, there's really no extremely reliable way in the protocol to know how many pages (more than 1) were involved in a fax reception.

Lee.


____________________ HylaFAX(tm) Users Mailing List _______________________ To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi On UNIX: mail -s unsubscribe hylafax-users-request@xxxxxxxxxxx < /dev/null *To learn about commercial HylaFAX(tm) support, mail sales@xxxxxxxxx*




Project hosted by iFAX Solutions