Re: [hylafax-users] What does this error message mean

["George H" <george.dma@xxxxxxxxx>]

Thanks for the explanation and the error codes are in 5.1.7 but this
error message doesn't have it. Either way, this error is a first after
10,000 faxes. Must be a problem from the sender.

Thanks again.

On 10/9/07, Lee Howard <faxguy@xxxxxxxxxxxxxxxx> wrote:
> George H wrote:
>
> >Using HylaFAX+ 5.1.7 and I got this odd error message when it was
> >receivng a fax. There is also no error code apppened to the end
> >between { }.
> >
> >"RCV FAX: PPM received with no image data. To continue risks receipt
> >confirmation"
> >
> >First time I see it.
> >
> >
>
> I believe that the error number in brackets was added in 5.1.8.  If not
> then it will be in 5.1.9 for sure.  I didn't add the error number
> initially because 1) I forgot to, and 2) the error condition was kind of
> experimental.
>
> It's a new error... and one that I felt was needed.
>
> In the case where (in non-ECM) we recieve a signal such as MPS or EOP
> but it's pretty clear that we missed the page image data altogether that
> corresponds to that signal (instead of simply needing to repeat our last
> response to the signal) - then we have to choose between signalling MCF
> (confirmation), RTN (page quality rejected, retrain required before next
> page), or DCN (disconnect).
>
> Responding with MCF would clearly get us into trouble because then we'd
> be confirming pages that we never got.  However, to some senders RTN
> amounts to a confirmation, but with the requirement that the next page
> be preceeded by retraining.  (This issue also applies to
> BadPageHandlingMethod.)  Many non-ECM senders are simply incapable of
> retransmitting the last page.  And so in some cases responding with RTN
> gets us into trouble as well... because to the sender's mind we're
> confirming a page that we never got in the first place.  To prevent this
> from becoming an issue and to make it clear to the sender that an error
> occurred and that the preceding page must be retransmitted and that it
> was not confirmed... we now therefore respond with DCN.
>
> If you see this kind of thing repeatedly happening with any particular
> sender (or all senders in general) then it probably represents a problem
> with the modem or with the line audio quality that is making it
> difficult for the modem itself to "train" on the signalling from the sender.
>
> 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*
>
>


-- 
"Nothing is impossible for the person that doesn't have to do it"
"The probability of anything happening is in inverse ratio to its desirability"
"The problem is not freedom of choice, it is about the choices you
have. Choice is always limited by the number of alternatives presented
to you"
--
George H
george.dma@xxxxxxxxx


____________________ 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*