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] REMOTE HANGUP: No response to EOP repeated 3
On 2003.08.11 05:40 Glenn Burkhardt wrote:
> > Aug 10 01:37:48.19: [ 2683]: SENT 28148 bytes of data
> > Aug 10 01:37:48.19: [ 2683]: <-- data [2]
> > Aug 10 01:37:48.37: [ 2683]: SEND end page
> > Aug 10 01:37:49.22: [ 2683]: --> [2:OK]
> > Aug 10 01:37:49.22: [ 2683]: SEND send EOP (no more pages or
> documents)
> > Aug 10 01:37:49.22: [ 2683]: <-- [9:AT+FET=2\r]
> > Aug 10 01:37:59.56: [ 2683]: --> [9:+FHNG: 54]
> > Aug 10 01:37:59.56: [ 2683]: REMOTE HANGUP: No response to EOP
> repeated 3
> > times (code 54)
>
> This has been a long standing problem, of course. Unfortunately, it
> results
> in many copies of the fax being sent, since Hylafax thinks that
> there's been
> an error during transmission (which there has been - the receiving end
> isn't
> following the Class 2 protocol, and is hanging up the phone before the
> session is over).
The receiving end isn't following T.30 protocol, the DCE-DCE standard
(device to device). Class 2 protocol (T.32) is a DCE-DTE standard
(device to software). And, according to your modem's response, we do
not know if it has hung up or not, but it certainly did not send DCN
(disconnect), and more likely is that your modem's Class 2 firmware
does not implement T.30 in the way the receiver expects, and so we get
an error.
This error, no response to EOP (as with no response to MPS), is very
vague. It can mean several things... the receiver may not have heard
our data carrier, the receiver may have had some problem with the data
we sent (i.e., they don't support 2D-MR as they claimed), the receiver
may have not heard the image-ending RTC signal and our data carrier
drop (lots of line noise?), the receiver may not have heard our EOP
signals, the receiver's telco may have disconnected them, the operator
may have turned off the receiver, it may have had a paper jam, or
everything may have gone fine except that it may simply wait to send
MCF until after it's printed out all the pages (or some other thing) -
and all this is assuming that all is correct on our end.
You'll probably have better luck with Class 1, but sometimes Class 1
still has this problem, and it has recently come to my attention that
maybe the best thing we can do is to send EOP more than three times.
But this doesn't help with Class 2 at all, since with Class 2 you
depend on the modem manufacturer to fix any firmware problems.
> I suggest that the code be changed so that if all pages have been
> successfully
> transmitted, that +FHNG be a "success" response to AT+FET=2.
>
> What does everyone think about this as a proposed solution?
This would be a grave mistake, I believe, since it assumes the last
issue on the list I gave when it may, if fact, be any of the others,
some of which would consequently prevent the image from being received
by the receiver at all.
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@hylafax.org < /dev/null
*To learn about commercial HylaFAX(tm) support, mail sales@hylafax.org.*