Re: [hylafax-users] Is DID required for this application?

["Donald, Adam" <adam.donald@xxxxxxxxxxx>]

Lee

Thank you for taking the time to explain your solution to me, this stuff is
interesting, and I am having fun learning more about it.  I am new to faxes
and to linux so it is entirely possible that I have something setup
incorrectly.

Originally, yes, the sending Multitech was being fed an analog line from the
phone switch.  

To test, I commented any of the lines out of my ttyS2 conf, and restarted
the faxgetty process.  I also ran a pots line that does not pass through the
PBX at any point directly to ttyS1.

I ran 'sendfax -h ttyS1@ -B 14400 -d 6152424 /etc/passwd' which resulted in
HDLC errors and some "Failed to properly detect high-speed data carrier."
messages.

I ran 'sendfax -h ttyS1@ -d 6152424 /etc/passwd' which resulted in a clean
transmission/receipt.

So, what do you think?


AD

-----Original Message-----
From: hylafax-users-bounce@xxxxxxxxxxx
[mailto:hylafax-users-bounce@xxxxxxxxxxx] On Behalf Of Lee Howard
Sent: Thursday, February 24, 2005 3:53 PM
To: Donald, Adam
Cc: hylafax-users@xxxxxxxxxxx
Subject: Re: [hylafax-users] Is DID required for this application?

On 2005.02.24 13:30 "Donald, Adam" wrote:
> Lee
> 
> In my tests, by only enabling ModemAnswerCmd: AT+FCLASS=1;A will cause
> the
> HDLC errors in both direct to modem and PBX to modem, when the sender
> is the
> Multitech.

Is the MultiTech sender sending through the PBX or is it direct also?

> However, when using our Canon Laserclass 9000 as the
> sender,
> both direct to modem and PBX to modem result in no HDLC errors.

That tells us that we're dealing with a *sender* problem isolated to 
the MultiTech.  It could be the modem, it could be the setup.

> Perhaps it
> is worth noting that the modem is always fed by a PBX supplied analog
> line.
> What I mean by "PBX to modem" is that the modem is in a hunt group off
> of
> the PBX which feeds the modem digits, and the fax is initiated by
> dialing
> the VDN rather than the modem's direct line.  Please also note that I
> assumed that you meant AT+FCLASS=1;A when you referenced AT+FCLASS=1
> below.
> If you had intended for me to try AT+FCLASS=1 (without the ;A), let me
> know,
> and I will run the tests again.  What does the ;+F34=14,1,2;A
> accomplish
> that makes Multitech to Multitech work without HDLC errors?

Long story...

HylaFAX initializes the modem.  You've set up your modem in Class 1.0 - 
which gives you support to V.34-Fax.  So, during the initialization 
process HylaFAX does this sequence with the modem:

   <-- AT+FCLASS=1.0
   --> OK
   <-- AT+F34=14,1,2
   --> OK

The "AT+FCLASS=1.0" command tells the modem to run in Class 1.0 
(basically making the +F34 command available to it), and the 
"AT+F34=14,1,2" command tells the modem to enable V.34-Fax.  It does 
this because you've configured Class1EnableV34Cmd as such.

Then HylaFAX just sits there, waiting for RINGs, in order to answer the 
incoming call.

Now, in order to read DTMF after answering, we have to switch out of 
Class 1.0 and into Class 8 (voice mode).  So we do this (with our 
ModemRingResponse):

   <-- AT+FCLASS=8;H1

That tells the modem to switch to voice mode and to take the line 
off-hook, listening.  Now, it's very possible that doing this "switch" 
to voice mode caused the modem to lose all of the fax-related 
intialization.  In particular, did it lose the V.34-Fax setting?  I 
don't know.  I don't even know if it is *supposed* to keep the settings 
or not.  But, in any case, we have to do switch to voice mode to get 
the DTMF digits...

And once the DTMF digits are received, then we need to switch back to 
fax mode and answer (with our ModemAnswerCmd).  So if we do this:

   <-- AT+FCLASS=1.0;A

It tells the modem to switch back to Class 1.0 and then answer the call 
fax-style.  But did we lose the V.34-Fax setting?  I don't know.  Your 
tests seem to indicate that it did.  So if we do this instead:

   <-- AT+FCLASS=1.0;+F34=14,1,2;A

Then it tells the modem to switch back to Class 1.0 and then re-enable 
V.34-Fax before answering.

Okay, well, so what?  Right?

Well, the point is, that when you send from your V.34-enabled MultiTech 
sender and then you're receiving with your V.34-enabled MultiTech 
receiver, then the fax is going to use V.8 (just a little) and (mostly) 
V.34 to communicate.  If one of them do not have V.34 enabled, then 
they will use V.17, V.29, V.27ter, (usually just one of the above) and 
V.21 to communicate.

Your logs indicate that there are no HDLC errors (caused by the sending 
stream having various "inserted 0xFF garbage") whenever V.34 is used or 
whenever V.29 (9600, 7200 baud) is used, but there are always errors 
when V.17 is used (14400, 12000, 9600, 7200 baud).

This means that something is wrong with some item in the sending stream 
that isn't happy with V.17.  I'd bet on the PBX as many, many people 
use these MultiTech modems for sending faxes, and the bulk of all 
faxing will occur with V.17.

So, go ahead and set up your receiver the way that it works for you... 
now that you know how to do that.  But now it's time to figure out 
what's wrong when you use the MultiTech as a sender in V.17.

Try sending a V.17 fax ('sendfax -B 14400') with that sending modem 
when it is not running through your PBX.  See if you get the HDLC 
errors then.

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*

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