Chapter 7. Living with real world T.38 entities.

Table of Contents

Non-ECM data ending immediately after the six EOLs denoting the end of a page causes corruption
Expect mixups between non-ECM and ECM image modes.
Expect some very poor timing decisions in various designs.
Which kinds of error correction to use.
What really ends the data?
Normal use versus testing

The T.38 specification leaves a number of grey areas, and many things can be implemented in several ways. It might, therefore, be expected that interoperability will not always run smoothly. Whilst some design decisions are reasonable subjects for discussion, it is quite common to find T.38 implementations doing things which are simply wrong.

Non-ECM data ending immediately after the six EOLs denoting the end of a page causes corruption

From the T.38 specification, a T.38 entity sending non-ECM image data should be able to end the image data, with t4-non-ecm-sig-end, at the last bit of the six consecutive EOLs which denote the end of a page. However, this offers poor compatibility with some implementations of T.38. They will drop their carrier signal prematurely, and the last few rows of the image will be corrupted at the receiver. This can happen regardless of whether the t4-non-ecm-sig-end is followed by a no-signal message, and regardless of the timing of that no-signal message. Padding with zero bytes for 40ms or more after the six EOLs seems to prevent this, and results in an image which exactly matches the one at the source.