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

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

Lee

Here is what happened when...
ttyS1 sends ---> ttyS2 receives
With -B 14400: 
Trains at v.17 (14400).  Produces HDLC errors and "Failed to detect high
speed data carrier." after the first page (of 2 pages).  When hylafax
auto-reconnects (and I do the faxanswer), it trains at v.17 (14400), then
limps through with more HDLC errors.

Without -B 14400:
Training line is not present in log (there is no line that reads, RECV
training ..., but fax is error free and transmitted in one try.

ttyS2 sends ---> ttyS1 receives
With -B 14400:
Trains at v.17 (14400).  Produces HDLC errors and "Failed to detect high
speed data carrier." after the first page (of 2 pages).  When hylafax
auto-reconnects (and I do the faxanswer), it trains at v.27ter (2400), then
finishes the fax without further errors.

Without -B 14400:
Training line is not present in log (there is no line that reads, RECV
training ..., but fax is error free and transmitted in one try.


AD
-----Original Message-----
From: Lee Howard [mailto:faxguy@xxxxxxxxxxxxxxxx] 
Sent: Friday, February 25, 2005 11:43 AM
To: Donald, Adam
Cc: hylafax-users@xxxxxxxxxxx
Subject: Re: [hylafax-users] Is DID required for this application?

Adam,

Okay, so it *looks* like something is wrong with V.17 and your sending 
modem(s).

So to test, add this to the modem config files (you'll probably want to 
remove it after testing):

   ModemDialCmd:  ATX3DT%s

Then take a phone cord and plug both modems together directly.  Plug 
the cable into both modems in the "line" jack.

Then send a fax using ttyS1 and V.17 ('sendfax -B 14400').  Watch 
faxstat.  When it says "sending job ...." (or, if external, you just 
watch for the OH light to come on) wait 5 seconds and then do 
'faxanswer ttyS2'.  The two modems should be faxing to each other 
directly.

Then do it the other direction, send with ttyS2 and receive with ttyS1.

Then let me know if those had those same HDLC errors.

Lee.


On 2005.02.25 09:29 "Donald, Adam" wrote:
> 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*