RS> It is now clear that for some nutty reason the Couriers alone choose to try
RS> for a V32terbo session, immediately after getting a perfect V32bis connect.

BG> Are you suggesting that a V.32terbo caller would
BG> first need to negotiate a V.32bis connect, then
BG> instantly attempt to renegotiate a V.32terbo connect ?

RS> I am saying that thats one possibility given USRs clear obsession with
RS> a very fast initial connect. They clearly do that even with V34, get
RS> an initial connect which doesnt wring the absolute most out of the
RS> available bandwidth and noise levels, and then push the envelope more
RS> once the connect has been achieved. And it seems pretty clear that
RS> that does actually reduce the overall session time significantly too.

RS> Its quite conceivable that they are attempting something like that with
RS> V32terbo too, PARTICULARLY when the S34 documentation goes on about
RS> 'the faster retrains that occur during proprietary V.32 terbo modulation'

BG> That's a totally illogical assumption.

RS> Nope.

BG> Yep.  Have another quote...

Nope, didnt help.

BG> =======================================================================
BG> Other V. Protocol Operations

BG> Earlier, lower-speed V. protocols do not employ line probing.

That isnt relevant to what we are discussing, V32bis, V32terbo, and V34.

BG> Instead, they use predefined answer tones to specify, or identify, speed
BG> capabilities.  These protocols define the following maximum speeds.

BG> *  V.32 terbo:  19.2K bps, with an additional Courier-to-Courier
BG>                            speed of 21.6K bps.
BG> *  V.32 bis:    14.4K bps.
BG> *  V.32:        9600 bps.

This is just plain wrong on V32bis, or mangling the story considerably.
It can in fact even do funky stuff like connect at 4800, negotiate at that
rate, and then do a rate renegotiation up to whatever the line can handle.

AND speed shift as the line changes thru the session as well.

With some modems like the Supra V32bis you can even specify what
speed you want to do the initial negotiation at, and individually
tick the particular speeds that can be used in the V32bis mode too.

BG> ASL (used in V.32 terbo and V.32 bis modes) is a strategy that allows
BG> the modems' receivers and transmitters to act independently of each other.

Thats just the split speed stuff.

BG> We have always featured a fallback/fall forward feature
BG> with error-correcting modems that allows them to slow
BG> down if there are problems with the phone line, in
BG> order to avoid data errors, and then speed up again.

That doesnt actually say you can do that between 14400 V32bis
and V32terbo tho. In fact, since the constellation pattern
is completely different, I dont believe you can.

V34 can change its constellation pattern on the fly, but V32bis
and V32terbo cant. In fact thats one of the main kludges in V32terbo.

BG> But the independence of the receiving and transmitting
BG> channels means that one channel or the other may slow
BG> down and then speed up, without affecting the data flow
BG> on the other. The result is more efficient line operation.

Again, not particularly relevant to the problem we are discussing.

BG> WARNING:  Answering V.32 terbo modems shift their serial port rate up
BG> to 38.4K (for 21.6K connections) if the calling V.32 terbo modem dials
BG> in at 21.6K.  The answering V.32 terbo modem then sends data to its
BG> computer at 38.4K bps.   V.32 bis modems shift their serial port rate
BG> to 19.2K bps in order to make 14.4K bps connections.  If your ocomputer
BG> or terminal does not support these higher serial port rates, you need
BG> to disable V.32 terbo and/or V.32 bis.  See Appendix B, Register S34.

Thats USR specific stuff. A rockwell V32bis modem will actually let
you run the port speed below the line speed if you want to do that.

BG> NOTE:  While many modems on the market now use the more efficient
BG> speeds, there may be a problem in answering older, "dumb" V.32
BG> modems at 9600 bps.  Register S28 is used to modify the duration
BG> of the extra tones used in V.32 negotiations, in the rare instance
BG> that this may be necessary.  See S-Registers, in Appendix B.

This is V32, not V32bis. V32 indeed is rather cruder on the handshaking.

BG> ======================================================================

I cant see that this lot has actually added anything.

BG> As an aside, it's a pity that Paul no longer has the Courier,
BG> as it might have been worth playing around with S28 as well.

Nope, thats V32 negotiation. AND you have never quite grasped that
the initial handshaking when calling the Courier is absolutely perfect
EVERY TIME. The problem is that after less than a second from the
CONNECT that is the result of that handshaking, THEN the Courier
mindlessly demands a full retrain if its got V32terbo enabled. Nuts.
@EOT:

---