-=> Quoting Craig Ford to Richard Town <=-
 RT> K56flex _is_ the amalgam of K56Plus and V.flex2 architecture.  
 RT> K56Plus does not interoperate with Livingston Portmasters (Lucent 
 RT> chipsetted) _only_  To others' kit it does. 
 CF> K56Plus and V.Flex/2 do not interoperate at _any_ level.
K56Plus will work to Ascend servers (Rockwell based)
Just not very well.  Stop spreading FUD
 CF> The K56Flex
 CF> protocol as used in the Livinston server is the _first_ implementation
 CF> of K56Flex, _everything_ else has been a bastardization of K56Plus.
That does not preclude interop and you carefully refer only to Lucent
in the above statement.  What K56flex does tho is increase the line
bit rate available at greater distances from the client's exchange.
K56Plus wasn't very good at that (ver.11* series)
As vers.502, 516, 1.01, 1.02 and Zoom's 1.02a have been issued so
there's been performance hikes.  It's called "continual development"
 CF> You would do well to look up who the real contributors to those
 CF> recommendations were.
Interop is all to me.  But not in the commercial interests of some,
it's transpired.  Any 3429 V34 symbol rate available with x2 yet in
the clent upstream "x2 connected" direction?
 
 RT> SG16 is bogged down in intellectual property rights' issues.  No
 RT> such problem for Open Forum members, of which ZyXel is one.
 CF> Mr. Townsend's pattents cover ALL applications, they affect K56Flex,
 CF> X2, and the ITU's V.PCM.
Have you read the spec?  If so, how?
There is no ITU v.pcm yet.  Which is why it's referred to in all
lower case
Mr Townsend's is only one of 16 competing claims
Mr Townsend's is only provisional, and unpublished as sealed final spec.
All patent agents worth their salt will make their client's claims as
wide as possible - it's in their client's interest (as well as their own :-)
So Craig, how do you _know_ Mr Townsend's patents "cover ALL applications,
cover K56flex, X2, and v.pcm"?  Or are you just blowing sycophantic smoke
on USR's behalf as you've been doing these past five years to my knowledge?
Is it true that you're trying to force Symmantic into only Class1 (1.0)
and Class2.0 operational modes only?  If so, why?  And in what way is that
in their interests?
 
 RT> No such problem for V.FC users too who often have to turn to this
 RT> proprietary protocol (where available) to avoid V34 incompatibility
 RT> problems with x2 upgraded USR product.
 CF> Rockwell isn't even supporting V.FC in their 56K chipsets, and where
 CF> problems exist, it is a simple matter of going down or up-level a ROM
 CF> version... X2 capability remains.
Over here there's only one x2 .sdl  And that destroys interop, from when
it was excellent (SDL.7778) to needing forced V32bis for non-VFC
V34Plus and K56flex modems; or forced V.FC from older.  I don't know whether
this is a function of switching off x2 in Couriers (to regain 3429 symbol
rate signalling) when in Mailer/BBS mode.  Or whether the drastic action
of reflashing back to .7778 is the only cure.
But whatever the cure on the USR side, opportiunity seems to have been taken
to only V34 negotiate with modems from the same manufacturer.  IE those
using USR's quaint methods of linespeed/bit rate signalling.
Other the years, I've spent more time and money than have had sense
freely collecting reports on these issues.  Some have been the fault of
Zoom (those sad first V34 factory defaults :)  But not anymore.  If I
come across a duff connect in my leeching then, a quick check in nodelist
and yup either H16 and/or X2C (and what a waste of space that flag is)
is egotistically displayed.  So I just shrug and move onto the next.
Leaving the USR-fitted system involved with one less user.
And me with more change in my pocket.  Eventually the penny will drop
with all those sysops.  Couriers are now starting to turn up in the
BUY echoes over here, and one of my point's reports sales of Zooms are
on the up...
rgdZ
Richard
--- FMail/386 1.02
---------------