IS> Perhaps Lewin can help with this, regarding how the
 IS> Rockwells can be tuned
[..]
 IS> with enough other
IS> makes of modem, thus are setting their BER / line rate selection policy
IS> toward only better lines.

 LE> You mentioned this a long time ago. All that high-level
 LE> stuff is supervisory and is completely customizable by the
 LE> implementor. *However* you are not likely to see modems
 LE> which use Rockwell firmware diddling with that sort of
 LE> detail very much. When an OEM makes a "really, really
 LE> template" AC modem solution he uses a utility called
 LE> ConfigurACE to customize a precompiled firmware image, he
 LE> does NOT recompile the ROM chez lui. ConfigurACE lets you
 LE> modify tonedet parameters, power-on defaults, OEM ID
 LE> strings, blacklisting, etc etc but it doesn't give you much
 LE> in the way of fine control over modem behavior the way
 LE> customized firmware does.

Mmm.  Most of the more 'generic' Rockwell kit doesn't seem to have this
problem, so much anyway.  Surely the V.42 negotiation period timeout is
adjustable?

 LE> So I would not expect to see E-series NetComms deviate from
 LE> Rockwell defaults, but I *would* expect the M-series
 LE> 68302-based modems and other from-scratch firmware sets
 LE> behave differently from the E-series under identical
 LE> conditions (unless NetComm deliberately emulated the
 LE> Rockwell decisions).

Well, I mentioned firstly the M34s, which seem to consistently respond that
way (as Bill mentions, the easiest way around for many people is to disable
V.42 detect phase, which points more toward a poor default timeout decision
than anything else), however the symptoms seem so far to be the same for a
local Roadstar 33600 job, which I'd imagine to be more an 'E' series type
of implementation, perhaps - that could be partly due to pilot error
though.

Thanks for that, glad to see you're paying attention :)

Ian

--- MaltEd 1.0.b5