Re: [hylafax-users] Quirks in T.30 implementations

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

Steve Underwood wrote:
> An ECM PPS frame contains a page number, a block number and a number 
> of FCD frames. The FCD frame count has a few quirks in various 
> implementations. Does anyone know if the block number and page number 
> can be relied on to follow the T.30 spec? That is:
>
> - the page number starts at 0 at the beginning of a call, and counts 
> up until the end of the call, wrapping after 255
> - the block number starts at 0 at the beginning of each page, and 
> counts up until the end of the page, wrapping after 255 

This is correct, and yes, it can be relied on.  In fact, it *must* be 
relied on or you risk defeating the guarantee that ECM affords.  For 
example, if after PPS-EOP we confirm block 0 page 0 and then 
subsequently the sender next transmits block 1 page 1 then we MUST NOT 
confirm it because we never saw block 0 page 1 at all.  If we confirm 
block 1 page 1 simply because we got that block in its entirety, we risk 
implying  to the sender that we also got the skipped-over block.

There is one place, however, where you're going to have to develop-in 
some leniency, and that's with the representation of zero in the frame 
count - in particular in a retransmission after PPR.  The spec does not 
explain how to represent a zero frame-count.  Is it with a 0 (which 
really means 1)?  Is it with 255 (which really means 256)?  I guess one 
could say that a zero frame-count block should never be transmitted, but 
what do you do when the receiver sends PPR with an indication that it 
needs no frames retransmitted?

Another place that you may want to consider is that some senders are 
going to be off-by-one in their frame count.  So if you're dealing with 
MH or MR (or possibly even MMR) data, it may not hurt to allow the last 
frame of the last block on a page to be lost.  So after you signal PPR a 
time or two looking for that last frame... if it never comes... it may 
be acceptable to assume that the sender has an off-by-one frame count 
bug.  With MH, MR, and MMR data you're not likely to lose too much image 
data in the trailing 256 bytes if it turns out that you really do lose 
it.  Remember that a good portion of that will be RTC or EOFB... so it's 
probably not a big deal anyway.  Be aware, however, that you CANNOT do 
that with JPEG or JBIG (and in-particular JBIG) because any data missing 
from those image types is sometimes catastrophic.

Thanks,

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*