PE> 2. USR Courier got failed connect to me.  The symptom is that
 PE> I get a 28800 connect with NO EC, then I get a stream of x'91',
 PE> then a swag of random junk.  The caller called again and the
[..]
 PE> 3. A USR Sportster V34 (regular caller) is having terrible
 PE> trouble calling me (where he had no problems when I was running
 PE> a USR Courier).  He gets a 28800 connect (so my Netcomm
 PE> reports) without EC, and then I receive a whole lot of x'11'/x'91'
 PE> then garbage.  In another variation he gets a whole lot of x'43'
 PE> before the x'11'/x'91' alternating sequence.  In one of these
 PE> instances, the USR owner reported a connect of 26400 whilst my
 PE> end reported 28800.  I do not know about the other instances.

The 0x11/0x91 are DC1 (^Q) of alternating parity.  Seeing them after
connect means that your modem has already decided it's to be a non
error-corrected connect, while the other end is still attempting to
negotiate LAPM.

The DC1s of alternating parity are known as LAPM Originator Detection
Pattern (ODP).  If the originating modem fails to detect returned Answerer
pattern (ADP) within a certain period, it will then send an MNP originate
sequence, if MNP is enabled.  These may be the 'C' (0x43) you're seeing, or
see below.

Note that this Data Link layer negotiation occurs after the Physical layer
is up, i.e. after V.34, Vfc, V.32bis etc., at the agreed negotiated rate,
has already been established.  Disagreement on rates gives different
'garbage'.

The answering modem will send all marks (1s) and look for incoming ODP, MNP
polls or LAPM protocol establishment phase.  If ODP is detected, it should
send ADP (alternating Es and Cs), then enter LAPM negotiation.  If LAPM
protocol phase is detected, it should enter LAPM negotiation.  If MNP polls
are received, it should respond with MNP negotiation (if enabled).  If no
protocol is detected, it will enter 'normal' (non-EC) mode, if acceptable.

You may have some S-register or other that adjusts how long the modem waits
before abandoning the LAPM detection phase, unless that's hard-coded?  If
possible, adjust this upwards 50%.  You may also do better setting demanded
sig.qual. for given connect speeds also upwards a notch or two - 24000/LAPM
connects perform as well or better than 28800/none, certainly more
reliably, and you'll still get 26400 or 28800 (EC) when mutual line
conditions permit.

Note: I'm speaking of LAPM generally here - do pay attention to John Clarke
and others who know them, for best tuning details for that particular
modem.

These sorts of problems are common with some modems; probably one reason
that some others choose to connect at a slightly lower speed, more quickly,
rather than risk missing protocol detection while still in asynch mode,
then shifting speed up a little later, after line conditions have settled
down longer.

Binkley's 'Protocol Negotiation Filter' exists to filter just those
characters out, avoiding confusing the session negotiation until these have
ceased.  The filter was much improved in versions after 2.56, and for the
last series of 2.59 betas may be disabled for known error-corrected
connects.  Here I use:

NoFilter /Lap-M  ; whatever matches a valid error-corrected CONNECT suffix.
NoFilter /Rel

which leaves the filter to do its thing on non-EC connects as described
above, while giving faster session negotiation when EC is known.  Of course
it's best to tune the modem to get EC connects wherever possible in the
first place.

Ian

--- MaltEd 1.0.b5