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

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

Lee

Thank you, again, for your insight.
I am running the latest firmware on our MT5634ZPX-PCI-U modems (both ttyS1 &
ttyS2).  Seeing as the solution you gave, AT+FCLASS=1.0;+F34=14,1,2;A, seems
to work well, how important is it that v.17 gets fixed?  Will this pose a
potential problem in the future if it doesn't get resolved, perhaps with
other modems or fax equipment?


AD

-----Original Message-----
From: Lee Howard [mailto:faxguy@xxxxxxxxxxxxxxxx] 
Sent: Friday, February 25, 2005 1:24 PM
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 both of your modems and 
V.17.  Try updating their firmware.  If that still doesn't help then, 
it looks like you need to go on to MultiTech's support chain.

You don't see training in V.34 because V.34-Fax doesn't involve it.  
The retraining and such is done by the V.34 protocol.

Lee.


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