TELECOM Digest     Wed, 6 Jul 94 23:51:00 CDT    Volume 14 : Issue 309

Inside This Issue:                          Editor: Patrick A. Townson

    New Telephone Numbers in the Netherlands (Dik T. Winter)
    Book Review: "TCP/IP Network Administration" by Hunt (Rob Slade)
    Big SS7 Problems (was Re: Int'l Calls to Taiwan) (Jim Gottlieb)
    IP to X.121 Translation? (Tudor Jebelean)
    Automatic Machines on a Network (Guillope Emmanuel)
    Telecommunications Developments at Western (Judy Noordermeer)
    COCOTs Lose Again (was Re: AT&T Keep In Touch) (Jim Gottlieb)
    NYNEX Says No Ringmate With Call Answering (Jeffrey W. McKeough)
    RFD: comp.dcom.cdpd (Bob Smith)
    Film to Video Transfer Unit (Alan Sieben)
    Info Highway - Virtual Factories (Lars Kalsen)
    Last Laugh! Dial 999 For Trouble! (Van Hefner)

TELECOM Digest is an electronic journal devoted mostly but not
exclusively to telecommunications topics. It is circulated anywhere
there is email, in addition to various telecom forums on a variety of
public service systems and networks including Compuserve and GEnie.
It is also gatewayed to Usenet where it appears as the moderated
newsgroup 'comp.dcom.telecom'. 

Subscriptions are available at no charge to qualified organizations
and individual readers. Write and tell us how you qualify:

                 * telecom-request@eecs.nwu.edu *

The Digest is edited, published and compilation-copyrighted by Patrick
Townson of Skokie, Illinois USA. You can reach us by postal mail, fax 
or phone at:
                    9457-D Niles Center Road
                     Skokie, IL USA   60076
                       Phone: 708-329-0571
                        Fax: 708-329-0572
  ** Article submission address only: telecom@eecs.nwu.edu **

Our archives are located at lcs.mit.edu and are available by using
anonymous ftp. The archives can also be accessed using our email
information service. For a copy of a helpful file explaining how to
use the information service, just ask.

*************************************************************************
*   TELECOM Digest is partially funded by a grant from the              *
* International Telecommunication Union (ITU) in Geneva, Switzerland    * 
* under the aegis of its Telecom Information Exchange Services (TIES)   * 
* project.  Views expressed herein should not be construed as represent-*
* ing views of the ITU.                                                 *
*************************************************************************

Additionally, the Digest is funded by gifts from generous readers such
as yourself who provide funding in amounts deemed appropriate. Your help 
is important and appreciated.

All opinions expressed herein are deemed to be those of the author. Any
organizations listed are for identification purposes only and messages
should not be considered any official expression by the organization.
----------------------------------------------------------------------

From: Dik.Winter@cwi.nl (Dik T. Winter)
Subject: New Telephone Numbers in the Netherlands
Organization: CWI, Amsterdam
Date: Thu, 7 Jul 1994 00:23:04 GMT


In October 1996 most telephone numbers in the Netherlands will change
(approximately 75% of all current telephone numbers).  The changes
occur for a number of reasons:

1.  To make all telephonenumbers equally long (when counting area code
    plus local number).
2.  To make most area codes shorter.
3.  To remove local numbers starting with the digit 1 (and also 7 to 9).
    This is due to a directive by the European Union where emergency
    numbers and other general numbers will start with 1 (digits 7 to 9
    will be reserved for competitors of the now monopolistic PTT).
4.  To remove area codes starting with 8.  Also due to an EU directive
    where area code 0800 will be used for toll-free numbers.

The changes do not apply for mobile telephones, free numbers and
premium numbers; although I suspect they will all change later.

Some history.  (Note: when I talk about n-digit area codes I include
the access digit, 0, because that is common practise overhere).  When
automatic non-local dialing was introduced the country was split in a
hierarchical system of area codes.  All codes were five digits, the
first the access digit, the next two the code for the district
exchange, and the following two were used for further refinement.  So
Muiden (in the neighborhood of Amsterdam) had area code 02942; a
subsection of sector Weesp (02940) which in turn was in the district
of Amsterdam (with area code 02900).  There were in total nearly 2000
area codes in use, distributed amongst about 15 districts.

Even before the automization was complete changes had taken place, the
area codes of the largest cities were reduced to three digits; since
that time Amsterdam has area code 020.  After completion a lot more
sectors have gotten three digit area codes, so currently there is a
mixture of three and five digit area codes.  Also since old times
local numbers were not equally long.  When a sector grew out of
numbers some numbers would get an additional digit prefixed freeing up
a lot of initial digits.  That is how the Amsterdam number 53121 was
changed to 953121 and later to 6953121.  Previously it probably was
3121.  This was not done for all numbers in an area code at once, so
it was very usual to have different length numbers within a single
area code.  Currently numbers are six or seven digits when the area
code is three digits, or three to five digits when the area code is
five digits.  This will change to universally a three digit area code
with a seven digit local number or a four digit area code with a six
digit local number.

This means that *all* numbers that do not fit this pattern will change
next year.  And that is all of the country except the three big cities
(Amsterdam, Rotterdam and the Hague), the (probably for you unknown)
entity of Almere and the small township of Almelo which will change
already this year.  There is no simple rule for number changes.  PTT
has issued a 44 page booklet describing the changes, and you need all
those pages; it will be distributed country wide next year.  A feature
of the change is that all old numbers will go through for six months
after the change (unlike when Belgium changed all numbers overnight,
quite some years ago.)  But this permissive dialing has its problems
(i.e.  more changes are made than would otherwise be needed).

How does it change (a global overview):

If the old area code was three digits (except 080 and 085) the area
code remains unchanged, and if the old number was six digits, a single
digit is prepended.  The digit prepended depends on the area code and
in some cases also on the initial digit of the old local number.  Area
codes 080 and 085 will additionally be changed to 024 and 026
respectively.

Otherwise the old area code was five digits.  There are two possibilities:

1.  The area is incorporated in a neighboring three digit area code area.
    In that case the local number will be prefixed by a number of
    digits to make the local number seven digits.
2.  The last digit of the area code is dropped.  The local number is
    prefixed to make the number six digits.

In all cases the prefix must be found in the conversion table and may
also depend on the initial digit of the original local number; and in
most cases the first digit of the prefix has no relation to the
dropped digit from the area code.

In addition, area codes in the range 083xx will move to the range 031x
and area codes in the range 088xx will move to the range 048x.
Moreover, Almelo (which changes this year) will go from 0549x to 0546.
And finally, rule two is not totally general, there are cases where
two or more new four digit area codes are combined, so that also the
final digit of the new area code is not totally predictable.

I think we will have some fun over here.


dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland, +31205924098
home: bovenover 215, 1025 jn  amsterdam, nederland; e-mail: dik@cwi.nl

------------------------------

Date: Wed, 06 Jul 1994 12:52:14 MDT
From: Rob Slade <roberts@decus.ca>
Subject: Book Review: "TCP/IP Network Administration" by Hunt


BKTCPADM.RVW  940328
 
O'Reilly & Associates, Inc.
103 Morris Street, Suite A
Sebastopol, CA   95472
800-998-9938   707-829-0515
fax: 707-829-0104
info@ora.com or nuts@ora.com
"TCP/IP Network Administration", Hunt, 1992, 0-937175-82-X
 
The growth of the Internet, in terms of the number of computers
connected, has been doubling each year for at least the last ten.
This means that in this coming year about three million computers will
get connected, and in the year following, approximately six million.
This growth cannot continue indefinitely.  One constraint is the
number of computers in the world, and another is the limit on the
number of numeric Internet IP addresses available.  One of the most
important limiting factors, however, is the availability of knowledge
about the connection and configuration of computers to the Internet.
This book addresses this latter problem.
 
If you are a UNIX system manager, this book is a thorough guide to
configuring an Internet connection.  (Even if you are not on the
Internet, it is an excellent overview of the requirements for using
TCP/IP to network your own machines.)  For some, the guide may be on
the technical side -- but then, network administration is a formidably
technical task.
 
The first three chapters discuss the concepts behind TCP/IP, routing,
and the domain name and name service.  The next four cover the basics
of connections and configuration.  Chapters eight to ten give details
on the primary network services.  There are also chapters on
troubleshooting, security and appendices, including Internet service
contacts, and the various application forms for registration.
 
If you are not working in UNIX, many of the low level specifics will
not be of much use.  Many of the items, however, can either be used as
rough outlines, or adapted to non-UNIX systems.  Many programs may be
different, but a lot of the structure, data and concepts will be the
same.
 
For those charged with the practical details of bringing a system into
the Internet, this book is uniquely helpful.

copyright Robert M. Slade, 1994   BKTCPADM.RVW  940328, Distribution 
permitted in TELECOM Digest and associated newsgroups/mailing lists.
 

Vancouver      ROBERTS@decus.ca    
Institute for  Robert_Slade@sfu.ca 
Research into  rslade@cue.bc.ca    
User           p1@CyberStore.ca    
Security       Canada V7K 2G6      

------------------------------

From: jimmy@tokyo07.info.com (Jim Gottlieb)
Subject: Big SS7 Problems (was Re: Int'l Calls to Taiwan)
Reply-To: jimmy@denwa.info.com (Jim Gottlieb)
Organization: Info Connections, Nakano-ku, Tokyo, Japan
Date: Wed, 6 Jul 1994 06:22:36 GMT


A recent article talked about problems calling Taiwan.  I would like
to propose that the carriers are all having severe problems with
regard to SS7 connectivity with foreign carriers.

Although I have almost no problems when calling to the U.S. from
Japan, I have had many problems calling Japan from the U.S. recently.

For example, I find that when trying to call a number in Japan that is
busy, instead of a busy signal I often get "The call you have made can
not be completed in the country you have dialed" from AT&T while
Sprint just gives a reorder.

A few weeks ago, I kept getting a "not valid" recording when trying to
call a Tokyo mobile number.  I got it to work only by adding a '0'
after the country code, something you're not supposed to have to do.
A few days later, it was working again, with or without the '0'.

The carriers need to take a serious look at these problems.

Jim Gottlieb <jimmy@denwa.info.com>        Info Connections, Tokyo, Japan
                                        Chuo 1-27-8, Nakano-ku, Tokyo 164
Fax: +81 3 5389 0188                          Voice Mail: +81 3 5389 1099

------------------------------

From: tjebelea@risc.uni-linz.ac.at (Tudor Jebelean)
Subject: IP to X.121 Translation?
Organization: RISC, J.K. University of Linz, Austria
Date: Wed, 6 Jul 1994 16:20:26 GMT


Dear colleagues,

This is a request for help.  Do you know how to translate IP address
into X.121 address?

More specifically (since I no nothing on the matter): I address
computers (for instance by telnet or ftp) with something like
"melmac.risc.uni-linz.ac.at", which is equivalent to a number, for
instance 193.170.36.100. Apparently this is called IP address.

However some computers are connected to the world in a way which does
not recognize this addresses. I know somebody in Romania who receives
mail through Sprint, and can also do telnet or ftp, however the
addresses he has to use look different: he told me this is called
X.121 format, and there should be a translation scheme -- but we do not
know it.

So the question is: does this make sense? Is there such a translation
scheme? How does it work?

Thank you very much for any help.  Please send it directly by e-mail
since I do not read this group.


Dr. Tudor Jebelean            phone:(Austria)7236-3231-50
RISC-Linz, A-4040, Austria    fax:  (Austria)7236-3231-30

------------------------------

From: News@goliath.france.NCR.COM
Subject: Automatic Machines on a Network
Date: 6 Jul 94 14:19:31 GMT
Organization: ATT GIS France


I want to connect automatic can dispenser machines on a network.  I
need advices to help us to investigate extraordinary solutions like:
wireless network transmissions on 110 volts wires spread spectrum, etc.
 
The rules of the "game" are simple:
 
There is NO telephone line near the machine. Data collection is
triggerred by a jam, empty state, etc or by a visit of technician for
cleaning and filling. It's a one way communication from a machine to a
server.
 
If anybody has an idea even special feel free to contact me 


GUILLOPE EMMANUEL / CSSD SUPPORT OCC / ATT-GIS France
BP101 98 RUE DE PARIS / 91301 MASSY CEDEX / FRANCE
PHONE #: (33)1 69-93-36-51 VOICEPLUS 3253651
FAX   #: (33)1 69-93-36-01 VOICEPLUS 3253601
EMAIL     #:Emanuel.Guillope@France.NCR.COM 

------------------------------

Date: Tue, 5 Jul 94 16:04:04 -0400
From: jnoorder@julian.uwo.ca (Judy Noordermeer)
Subject: Telecommunications Developments at Western


LEADING-EDGE MEDICAL NETWORK TO RECEIVE $2.2 MILLION
IN PROVINCIAL FUNDING

June 13/94
 
An innovative fibre optic network linking London's leading medical
institutions will receive $2.2 million from the provincial government,
Frances Lankin, minister of economic development and trade, announced
at Western today.

LARG*net -- London and Region Global Network -- will connect The
University of Western Ontario, Robarts Research Institute, University
Hospital, St. Joseph's Health Centre, Victoria Hospital, the London
Regional Cancer Centre and Fanshawe College.

The high technology network will allow the seven health care delivery,
education and research institutions shared access to medical imaging
databases, research data, information resources, video training and
teaching cases.  By sharing information, they will save invaluable
time and money and learn from each others' expertise.

"The network represents the collective excellence that London
possesses in terms of telecommunications, health care delivery and
education," says Dr.  Trevor Cradduck, professor and chair of the
division of nuclear medicine at Western and general manager of
LARG*net.

"Quite distinct from the developmental and research aspects of the
network, I believe the infrastructure will also be crucial to helping
the health care and educational institutions collaborate more
effectively and efficiently," he says.

The LARG*net experience will be watched carefully across North America.

"LARG*net will benefit not only Western, but the entire community,"
says Michael Gourley, vice-president of administration at the
University.

"The network brings London to the forefront of the information and
telecommunications revolution.  The implementation of this initiative
leads to the type of high technology investment and jobs which the new
economy demands," he says.

The provincial government contribution to LARG*net represents 40 per
cent of the total cost of the project.  The funds were made available
through the Ontario Network Infrastructure Program, a jobsONTARIO
initiative.

For more information, contact Dr. Trevor Cradduck, LARG*net general
manager, at (519) 667-6574, or Judy Noordermeer, Public Affairs Officer, at
(519) 661-2046.

     
Judy Noordermeer    Public Affairs Officer
University Relations and Information
(519) 661-2046   Fax: (519) 661-3921

------------------------------

Date: Wed, 6 Jul 94 15:02 JST
From: jimmy@denwa.linc.or.jp (Jim Gottlieb)
Subject: COCOTs Lose Again (was Re: AT&T Keep In Touch)
Organization: Info Connections, Nakano-ku, Tokyo, Japan


In article <telecom14.308.7@eecs.nwu.edu> is written:

> Will the AT&T Keep In Touch PCMCIA modem work with an acoustic
> coupler?  We have a group of salesmen who need to connect from phone
> booths.

Here in Japan, NTT is rapidly replacing all public telephones with a
new model containing both digital (ISDN) and analog data jacks.  I
would say that about 80% of the public phones near where I live have
already been upgraded.  Companies like Sharp and Casio are introducing
products to take advantage of this ubiquitous data connectivity.

Under current conditions this will never happen in the U.S.  The
telcos can't afford to do this when they are competing against sleazy
private pay phone operators who would never make this kind of
investment.  So while the Japanese will be able to plug in anywhere,
U.S. residents are still stuck with acoustic couplers.  Yuck!


Jim Gottlieb <jimmy@denwa.info.com>   Info Connections, Tokyo, Japan
                                   Chuo 1-27-8, Nakano-ku, Tokyo 164
Fax: +81 3 5389 0188                     Voice Mail: +81 3 5389 1099

------------------------------

Date: Wed, 06 Jul 1994 07:15:28 -0400
From: jwm@student.umass.edu (Jeffrey W. McKeough)
Subject: NYNEX Says No Ringmate With Call Answering
Organization: University of Massachusetts, Amherst


While I had intended to read replies to the post I sent in regarding
Ringmate before ordering, I decided yesterday to call NYNEX to verify
that the service is indeed available in my area.  I was told by two
individuals that Ringmate is incompatible with Call Answering on the
5ESS.  I remember reading in the archives that at least one person
(was it you, PAT?) in fact had both features and was served by a 5E.

I am assuming that the interaction is between Ringmate and the
Busy/Don't Answer forward that is installed along with Call Answering.
(Since the switch really shouldn't care what the Octel system does.)
My aunt at SNET said that this feature combination works fine on the
5ESS switches that she oversees.  She speculates that it could be a
tariff issue, i.e. NYNEX never got approval to offer B/DA forwarding
in combination with Ringmate.

So, does anybody out there have these two features on a 5ESS?  And if
it isn't a technical problem, is there anything I can do to try and
get the service that I would like?


Jeffrey W. McKeough   jwm@student.umass.edu
P.S. Responses to my other questions would still be appreciated!

------------------------------

From: Bob Smith <bsmith@rahul.net>
Subject: RFD: comp.dcom.cdpd
Organization: a2i network
Date: Wed, 6 Jul 1994 16:48:31 GMT


                      REQUEST FOR DISCUSSION (RFD)
                            comp.dcom.cdpd

(This is **NOT** a Call For Votes.  A Call For Votes will be issued in
the groups to which this message is posted 21 to 30 days from the date
that this message first appears. Voting is to be recorded by a neutral
third party.)

Group Name:     comp.dcom.cdpd
Status:         Unmoderated
Summary:        Discussion of all aspects of Cellular Digital Packet
                Data (CDPD), including discussions of carriers, services,
                applications, specifications, and noteworthy events.
Distribution:   World

                                CHARTER

CDPD is wireless protocol which offers low cost and ubiquitous radio
coverage to TCP-IP networks.  The technology uses the idle voice
channels available in the existing cellular telephone system for
packet data transmission. Application interface to CDPD can be via
telnet, SLIP, UDP, or TCP.  A CDPD modem uses the AT command set and
has an IP address which is assigned by the local cellular company
(just as your cellular carrier assigned the phone number to your
cellular phone). CDPD may be the preferred remote/mobile WAN since the
time and cost overhead of a cellular call establishment is not
present.

The aim of comp.dcom.CDPD would be to provide an informal electronic
conference for anyone curious about, or involved with CDPD. It is hoped
that the group may further the understanding and awareness of CDPD. 

CDPD's success requires the cooperation and coordination of many
diverse players: application developers, system integrators, cellular
carriers, infrastructure manufacturers, and modem manufactures. A
newsgroup where ideas, suggestions, and questions can be freely
exchanged is needed to help tie these players into an industry.

The FAQs would be an important part of the newsgroup and would include
as a minimum:

        FAQs about the nature and scope of CDPD
        a list of CDPD carriers and services offered
        a list of CDPD modem manufacturers
        a list of other CDPD products available

This newsgroup would allow the rapid and timely discussion of CDPD
related issues and events which might otherwise never be fully
disseminated.

Topics for discussion would include :-

        Product announcements
        Press releases of interest to the CDPD community
        Innovative CDPD applications
        CDPD deployment issues and plans
        Interpretation of the CDPD specification
        Infrastructure hardware: NMS, MDBS, MD-IS, ...
        Infrastructure software: NMS, MDBS, MD-IS, ...
        Modems - specifications, opinions, etc.
        New product ideas
        Databases, lists of...
        CDPD security, encryption, and firewalls
        Announcements/reviews of papers/conferences
        Comparisons to alternatives such as RAM, Ardis
        General discussion/opinions/questions.
        Positions vacant
        Professional news
        Economic issues

We hope that you will support this group, and look forward to your
comments and participation in the discussions in news.groups.

Please distribute this proposal to your friends and colleagues.
This RFD has been posted to:
        alt.digital.radio
        comp.dcom.lans.misc
        comp.dcom.modems
        comp.dcom.telecom
        comp.os.ms-windows.networking.tcp-ip
        comp.os.ms-windows.programming.networks
        comp.protocols.misc
        comp.protocols.tcp-ip
        comp.std.wireless
        news.announce.newgroups
        sci.geo.satellite-nav

Thank you.


The Process of Creating a Newsgroup

(a) RFD: Request for Discussion, i.e.., public hearing to take place in
           the newsgroup news.groups on Internet for approximately one
           month
(b) CFV: Call for votes (the voting period will be about 25 days)
(c) Counting of votes and public display of votes
(d) Announcement of new newsgroup

(a)-->(b) assumes no major disagreements about this newsgroup during
           discussion.
(c)-->(d) assumes that the vote is favorable, i.e., Y > N+100 .and.
           Y > (2/3)(Y+N)

Y being the number of YES votes, N being the number of NO votes for the
creation of the proposed newsgroup.


Bob Smith <bsmith@rahul.net>

------------------------------

From: Alan_Sieben@mindlink.bc.ca (Alan Sieben)
Subject: Film to Video Transfer Unit
Date: Wed, 06 Jul 94 16:38:05 PDT
Organization: MIND LINK! - British Columbia, Canada



I'm looking to purchase an ELMO TRV S8 film to video transfer unit.
This unit is no longer made by ELMO.  It transfers Super 8 film to a
video signal thatu can be recorded on tape.  Also interested in
anything else that transfers home movie film to video. Post here
or reply to alan_sieben@mindlink.bc.ca.

------------------------------

From: dalk@login.dkuug.dk (Lars Kalsen)
Subject: Info Highway - Virtual Factories
Date: 6 Jul 94 21:12:43 GMT
Organization: DKnet


Hi - out there,

I have a question concering what is called the The National
Information Infrastructure in US - the Information Superhighway.

I have a feeling that with such an infrastructure you could have a
more decentralized production.  You could link factories together and
production could be where the workers and raw materials are.  In fact
you could think of VIRTUEL FACTORIES where many production facilities
were linked together acting as one ordinary factory. The different
production facilities could of course have different owners.
 
Have you heard about similar ideas or seen articles about this
subject? Please email me with any peace of information -- or send an
articles to this newsgroup with your thoughts.


Greerting from Denmark,

Lars Kalsen    dalk@login.dkuug.dk

------------------------------

From: VANTEK@aol.com
Date: Mon, 04 Jul 94 18:57:52 EDT
Subject: Last Laugh! Dial 999 For Trouble!


WIRES CROSS AS LOVERS DIAL M FOR MOTHER

LONDON, July 2 (Reuter) - A terrified British mother put police on red
alert after mistaking the sound of lovemaking for a cry for help from
her daughter.

The Independent newspaper said on Saturday that two accidental phone
calls woke the woman in Devizes, southern England, in the small hours
of the morning.

Hearing moaning, groaning and shouting, she dismissed the first as an
obscene call, but in the second she recognised her daughter crying:
"Oh my God," and heard a man's voice.

Convinced her daughter was being attacked in her bedroom 100 miles
(160 km) away, she dialled the emergency number 999 and a police squad
sped to the daughter's home to investigate.

"Officers rushed round and found she wasn't being attacked -- in fact
she was quite willing," a police spokesman said.

"They explained that during the moments of passion one of the couple
accidentally pushed the last-number redial button on the bedside
telephone with a toe. Unfortunately on both occasions it was the
girl's mother's phone number," he said.

"This is a warning for other people -- if you're going to indulge in
this sort of thing, move the phone."

The mother and daughter have apologized to police for the confusion.

------------------------------

End of TELECOM Digest V14 #309
******************************
