[comp.dcom.modems] A European perspective on modems, from FidoNews

gnu@hoptoad.uucp (John Gilmore) (05/05/87)

[I have added some American comments of my own at the end. -- hoptoad!gnu]

FidoNews 4-17                Page 11                   4 May 1987

Steve Townsley
Opus / SEAdog 510/17
CCITT V21,V23,V22,V22bis

		  A Word About Standards


This  is  the first time I have written and article for  FidoNews
although  in England I will write around 3000 words every  couple
of  weeks  or  so. The main problem is not the  material,  it  is
rather  the  problem  of  incompatibilty  which  prevents  us  in
Europe getting our message to you in the States.

For  many  of you reading this sending an article to FidoNews  is
a  simple  affair,  file  attach to 1/1 at 2400  using  your  USR
modem  or  "real" Hayes. The FCC cares very little as to  whether
your  modem is a Taiwanise Hayes clone, runs CCITT tones or  BELL
103/212a.

Over  in the UK things are very different. Firstly, in order  not
to  receive  a visit from the authorities I have to use  a  modem
which  has  gone  through a series of approval  tests.  Secondly,
few  of these modems use BELL tones. Thirdly, all must adhere  to
the  recommedations  of the CCITT. Fourthly, approval is a  long,
complicated and expensive process for all modem manufacturers.

Converting  into  dollars, the cheapest useable,  approved  modem
which  could  be  described  as Hayes is  the  WS4000.  It  costs
around  $300  and  will  auto-answer  at V21  or  V23.  It  is  a
variation  of  Hayes  1200 as it will auto-answer at 300  bps  or
1200/75, but mail can only be done at 300 bps (V21).

The  V23  standard  is a popular in Europe  because  of  Viewdata
services,  where  it  is a standard speed,  and  for  downloading
over  crummy  phone lines, of which there are many. A  V23  modem
can  be  picked-up for $10 by anyone. So for the user of  systems
in  Europe a V23 modem is the cheapest way into comms. The  75bps
channel  allows the user to type in messages at typing speed  and
the 1200 bps channel allows cheap downloading.

The  crunch  for  UK  Sysops  is that  providing  access  to  V23
callers means eiher spending $600 on a modem with V22 as well (to
talk  to the States), or buying a $300 Hayes and sending mail  at
300 bps. Hayes modems in the Uk which use V21/23 are 1200 bps for
our users but only 300 bps for Sysops.

Obviously  we  should  buy  modems  that  use  V21,V23  and  V22.

However  now you are lokking at prices of around $600 dollars.  A
real  "Hayes"  1200/1200 modem costs around $750.  Moreover,  the
real  "Hayes"  does not use V21 or V23, and combined  modems  use
the  CCITT recommendations on V22. Yes, the tones are  compatible
with  Bell 212a but, V22 modems will often wait for a V25  answer
tone  before  sending any data. So the UK sysop, even if he  buys
a  V22  modem  still  may  not be able to send  data  to  the  US
because   a  BELL  212a  modem  does  not  send  an  answer  tone
compatible with the CCITT V25 recommendation.

Perhaps  we  should  buy a V22bis modem. Well  prices  in  Europe
start  at  around $1100 dollars although the Dowty  Quattro  with
such things as BELL 212a compatiblity comes in at just $1300.

Remember  we  still have to offer V23 to our callers whose modems
change hands for around $10.

However,  let  me suppose that we in Europe suddenly  solved  all
the  problems  of the modems, our next problem would  be  getting
the  modems  to  send  CONNECT  1200  everytime  a  CONNECT  1275
happened because both Fido and Opus don't understand about V23.

SEAdog  (Version  4.0) solves the problem by accepting 1275 as  a
proper connect message.

Let  me  assume that  the IFNA Committees insist  that  all  Fido
compatible  software must accept CONNECT 1275 as a valid 1200 bps
message,  not  unreasonable since it is merely an  ASCII  string.
The  problems  of  Europe  would still not  be  totally  over  as
currently  we are fast loosing our position in the nodelist.  The
1200  node  limit  of Fido is most accutely a problem  in  Europe
and  Austrailia.  If you cannot mail someone without  an  address
and  you cannot keep the addresses of all nodes in the system  we
will  add just one one more problem into the cumulative  problems
of international links that we had from day one.

As  we  run Opus, the other week, in an effort to find  out  more
about  aspects  of these problems, I logged onto the Dallas  Opus
Help  BB  run by David Finster. In a sense I was pleased to  read
the  questions YOU, the US Sysops, are now asking about 9600  bps
modems. For, in your own way, you are now experiencing first hand
the  frustration  of non-standards that have plagued Europe  from
day one of running Fido.

European  BBS's,  and  other  suppliers  of  data  services,  are
governed  by the international standards of the CCITT. Non of  us
really  like  the idea that we cannot use BELL tones,  or  cannot
just  plug a USR 2400 bps straight online legally. We don't  like
the  idea that we cannot participate fully in net  activity until
we can communicate at a common standard.

I  would  now argue that with the growth of nets outside  the  US
and  the  large number of systems that need to use the  standards
imposed  by  the  CCITT  that the net should  have  a  policy  on
standards.

Up  until  now  it has been the cry of Europe, unable  to  afford
the  high  price of approved CCITT equipment, that has wanted  an
agreed   standard.  I  would  argue  that  "standards" is  now  a
net-wide  issue.  If US Sysops are to go 9600 bps, and they  have
an influence on how modems are to be designed, they should insist
that  modems  are capable of communicating at  CCITT  recommended
data  rates  as  well  as  BELL or  one  manufacturer's  own  new
standard.

Many  US  Sysops  must have noticed that more and  more  European
BBS's are now  offering  2400  bps.  Little  by  little  European
manufacturers are offering some compatability with US BELL tones.

It  has taken the best part of two years to get UK  manufacturers
to  adopt  the Hayes standard. Only some offer BELL tones.  There
should  be  no reason why a modem cannot listen to a phone  line,
determine  whether an incoming call corresponds to BELL or  CCITT
standards  and  answer  with the correct tone. We in  Europe  are
constantly  campaigning for such a modem. Whilst debating the use
of  9600  bps,  all of you in the US should demand a  modem  that
talks  to  the  world and not just Joe Public in the  next  town!

The  moral of this tale... Europe has suffered because the  CCITT
standards  are  not universal. In the next speed jump to 9600  we
must  adopt  a  standard that can be approved for  connection  to
the  phone  line in any country in the world. This may mean  that
that  whatever  modem is choosen it must use CCITT tones  or  yet
again we could face years of incompatibility.

--------

Comments by John Gilmore (hoptoad!gnu on Usenet):

I think the best solution involves the Europeans fixing their
phone/government bureacracies so that they can use whatever modems they
want.  We in the US had the same problem through the early 1970s and we
fixed it.  (I must say I had no part in the fixing of it -- I was a bit
young.)  We've been plugging random modems into the phone wires for
years now and the phone system has not melted down.  Europe's turn.
I suspect the first step is widespread disregard for the rules, e.g.
just get a modem and plug it in.  They won't be able to hire enough
people to come by and hassle you over it if everyone does it.

If a modem user can buy and attach whatever modem they choose, they
won't be stuck with CCITT standards which don't follow the market, or
with expensive modems you can only get from The Phone Company.
Nobody can predict where the market will go or which modems will end
up cheap and widespread.

On the technical end, we can certainly press for modems which implement
a variety of standards, but in many cases the standards are incompatible.
For example, you can't determine whether an INCOMING call corresponds to
Bell or CCITT tones, because the ANSWERING modem is the first to produce
tones.  I think this is backward, but it has been backward for years.
Kludges like first answering with one tone, then switching to another,
work after a fashion, but not if you have a list of 10 or 15 different
protocols to test for -- the caller will hang up before you get to the
right protocol!

Certainly there is economic incentive for manufacturers to support as
many standards as they can, but there is also incentive to keep their
modems cheap.  More standards mean more design time, more components,
more testing, more upgrades in the field due to more bugs -- in short,
higher prices.  YOU can support the companies that handle many standards
by buying a high priced modem.  Well?  What are you waiting for?

Another option is for the European sysop to simply buy several modems --
a $10 modem for the Teletext callers and a $300 modem for the 1200/1200
callers.  This requires two phone lines, or fancy juggling, but does
not seem as bad as buying a $600 modem that does both.  Oh, your software
doesn't support two modems?  Well, you shouldn't have bought an MSDOS
machine anyway.  You get what you pay for.

I think it's also time for the death knell of software with wired-in
modem control strings and responses.  Unix uucp, tip, and getty are
notorious for this, as are many other programs inherited from the days
before inline serial dialers and multi-speed modems.  A simple interpreted
language would suffice for sending strings to the modem, checking the
results, and providing for different alternatives depending on the
response or lack thereof.  Having to get a new release of a program to
cope with "CONNECT 1275" rather than "CONNECT 1200" (as FIDO sysops do,
or as I've had to do to use USR 2400's on my Sun Unix 3.0 system) is
ridiculous given the overall somewhat advanced state of software.
Let us not let Unix System V's removal of split-speed (e.g. 1200/75)
support not go unremarked either!
-- 
Copyright 1987 John Gilmore; you may redistribute only if your recipients may.
(This is an effort to bend Stargate to work with Usenet, not against it.)
{sun,ptsfa,lll-crg,ihnp4,ucbvax}!hoptoad!gnu	       gnu@ingres.berkeley.edu