TELECOM Digest     Wed, 30 Mar 94 12:22:00 CST    Volume 14 : Issue 155

Inside This Issue:                           Editor: Patrick A. Townson

    Newton PCMCIA Fax Modem to Cellular (Gregory Youngblood)
    Switch Problems (From OPERS-L) (Paul Robinson)
    Local Charges for 950 and 800 Access? (John R. Grout)
    History: Vail, Monopoly, AT&T (James H. Haynes)
    Re: Pacific Bell Voice Mail Types (Todd Inch)
    Re: Observations About Area Code Splits (Bob Goudreau)
    Re: Observations About Area Code Splits (Dave Niebuhr)
    Re: Observations About Area Code Splits (Danny Padwa)
    Re: AT&T Cellular Privacy System (Steven King)
    Re: Voice and Data Through PBX (David Hough)
    Re: Voice and Data Through PBX (James Slupsky)

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.
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 compilation-copyrighted by Patrick Townson Associates of
Skokie, Illinois USA. We provide telecom consultation services and
long distance resale services including calling cards and 800 numbers.
To reach us:  Post Office Box 1570, Chicago, IL 60690 or by phone 
at 708-329-0571 and fax at 708-329-0572. Email: ptownson@townson.com.

    ** 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 gatewayed to Usenet where it appears as the moderated
newsgroup comp.dcom.telecom. It has no connection with the unmoderated
Usenet newsgroup comp.dcom.telecom.tech whose mailing list "Telecom-Tech
Digest" shares archives resources at lcs.mit.edu for the convenience
of users. Please *DO NOT* cross post articles between the groups. 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.
----------------------------------------------------------------------

Subject: Newton PCMCIA Fax Modem to Cellular
From: zeta@tcscs.com (Gregory Youngblood)
Date: Tue, 29 Mar 94 21:15:48 PST
Organization: TCS Computer Systems


eskin@brooktree.com (Michael Eskin) writes:

> I am looking for recommendations for equipment and experiences in
> sending data and fax from a Newton MessagePad 110 with the internal
> Apple PCMCIA Fax Modem using an external interface to a Mitsubishi
> 4000 pocket cellular phone.

> Can it work? I am pretty much limited to 2400 baud data by the speed of
> the Newton so a basic data connection is all that is needed.

> I've heard reports that this should work, others that it shouldn't. I am
> looking for some real data.
 
Assuming that you can plug the PCMCIA Fax Modem into a phone line and
it works, and you have the RJ11 interface for the Mitsubishi 4000, and
you realize you'll have to disable dial tone detection and dial the
number on the mitsubishi and press send yourself (unless you've got an
interface that provides dial tone and/or can automatically dial the
numbers) it should work.  2400 is no problem.  I know I can send a fax
at 4800 on cellular without the best conditions, and that's going
thruogh ADPCM connections from the cell site to the switch (I run the
cell sites and soon will have a local switch to run too).
 
I also know 2400 is no problem data wise.  Just today I did a UUCP
poll via cellular at 2400/v.42 bis, as well as a few 1200 data calls
as well.  If your going to do 2400, then it would be a very good idea
to have some form of error correction, otherwise your more prone to
see lots of garbage..unless your in a great area.  Faxes, I believe,
have a built in form of error correction, though I don't know anything
about it.


Greg
The Complete Solution BBS     Allfiles List:    Anonymous UUCP Calls Accepted
707-459-4547 (24hrs, v.32)    ~/tcsbbs.lst      Login: nuucp  Password: nuucp
Telemate Distribution Site  zeta@tcscs.com      Cellular Telephony Groups

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

Date: Wed, 30 Mar 1994 11:49:01 EST
From: Paul Robinson <PAUL@TDR.COM>
Reply-To: Paul Robinson <PAUL@TDR.COM>
Subject: Switch Problems (From OPERS-L)


The following was posted on the OPERS-L list on bitnet (Mainframe 
Operations).  Perhaps someone on TELECOM Digest can help Mr. 
Osterlin with his problem.  Please reply directly to him:


 Date: Fri, 25 Mar 1994 11:57:09 -0600 (CST)
 From: Bob Oesterlin <oester@vnet.IBM.COM>
 Subject: Digital Telephone Switches and Modems
 
Early last month, our local phone company (US West) replaced our
"aging" analog telephone switch with a new digital one, which was
designed to bring us "into the information age".
 
Well, no sooner was the switch installed, people started having
problems connecting to our dial-in service for home terminal support.
The current system consists of a front-end box (made by Traqnet) and a
Cisco terminal server.
 
The problems seemed to be widespread but intermittent:
 
- Dropped connections
- Can't connect at 14.4 KB (drops back to 1200!)
- Can't connect at all
 
After some lengthy (and still ongoing) investigation, the problem
turned out to be that the time bases of three digital switches involved
are not in sync! The three are:
 
- The Rochester switch (run by US West)
- The IBM Rochester Local ROLM switch (local PBX)
- The NPN Switch (which connects IBM to the corp network run by Advantis, 
Inc)
 
Comments from our local communications rep:
 
"I have been told that there are three national master clocks. Each
phone company must sync their digital switch with one of these master
clocks."
 
"U.S. West's switch is sync'd with a master, I don't know which."
 
"NPN's switch is sync'd with a master too, this may be the same master
that U.S. West is sync'ing to but, this is not important yet."
 
"Our ROLM switch is sync'd with NPN and cannot be changed."
 
BTW, the problem "seems" to be getting worse as time passes.
 
It would seem to me that this could become a widespread problem as
more DSS's are used. Is someone causes a master clock to become out of
step, then you could (potentially) disrupt communications over wide
areas.

 
Bob Oesterlin, IBM AS/400 Division, Dept 54T, Rochester MN 55901
oester@vnet.ibm.com  (IBM IPNET: oester@rchland.ibm.com)  (507)-253-4528  

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

From: j-grout@uxa.cso.uiuc.edu (John R. Grout)
Subject: Local Charges for 950 and 800 Access?
Date: 30 Mar 1994 17:19:23 GMT
Organization: University of Illinois at Urbana
Reply-To: j-grout@uiuc.edu


Does the FCC permit _local_ call charges for calls to 950 exchanges or
to 800 LD numbers?  If so, which states/telcos do in fact allow/make
such charges (at telco-operated payphones, or on lines for which telco
makes a charge for each local call)?

I remember having to pay for such a call at a C & P-operated payphone
in Maryland ... so that might be one such state/telco combination.


John R. Grout   | INTERNET: j-grout@uiuc.edu


[TELECOM Digest Editor's Note: Generally it is only the rip-off
private payphones (COCOTS) which have charges for 950 and 800. They
are not supposed to either, but they get away with it. I am surprised
it was at a C&P phone. Maybe there was a programming error.   PAT]

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

From: haynes@cats.ucsc.edu (James H. Haynes)
Subject: History: Vail, Monopoly, AT&T
Date: 30 Mar 1994 06:51:05 GMT
Organization: University of California, Santa Cruz


There's some interesting stuff in the new book, "The Story of
Telecommunications" by George P. Oslin.  Oslin is the 93-year-old
former PR man for Western Union.  A lot of the following is quoted
from the book, slightly altered.

Theodore N. Vail was related to Alfred Vail, one of Morse's partners
and one of the most important inventors in early telegraphy.  Theodore
was a telegraph operator, got a job as a mail clerk on trains, and
improved mail handling so much that he was called to Washington in
1873 to improve the railway mail.  In 1876 he was appointed General
Superintendent of Railway Mails.  He quit to join the Bell Telephone
Company in 1878.  He was given charge of the territory within a
33-mile radius of New York.

An experimental office was used at the Holmes Burglar Alarm Company at
194 Broadway [note that Western Union headquarters, and later AT&T
headquarters was at 195 Broadway].

AT&T was incorporated in 1885 as a long-distance subsidiary of
American Bell, with Vail as president.  He resigned as president in
1887 because he was dissatisfied with the American Bell president and
directors declaring a dividend payment instead of plowing the profits
back into the company.

In 1907 AT&T was was in dangerous financial condition.  The bankers
asked Vail to return as president.  At first he refused, saying that
at sixty-two he was too old, but he had just sold a South American
transit development for $3 million, his wife and son had died, and he
needed to keep busy, so he accepted.

At the time Western Union had a near monopoly on the telegraph
business.  It was owned by Jay Gould and run by his man Thomas Eckert;
they ran the business for their own profit and left it in seedy
condition.  Vail in contrast stressed service, cultivated public
relations, was popular with the press for keeping the public informed.

In 1909 AT&T was rich enough and WU was poor enough that AT&T bought
control of WU and made Vail the president.  Goes on to tell how Vail
made over WU with redecorating offices and raising salaries.  AT&T
moved its headquarters into the WU building at 195 Broadway after a
$1.3 million improvement.  In 1913 the Justice Department complained
about the communications monopoly and AT&T agreed to divest WU.
Newcomb Carlton because president of WU and continued Vail's policies
there.  Vail resigned from AT&T because of ill health in 1919 and died
the following year.


haynes@cats.ucsc.edu  haynes@cats.bitnet


[TELECOM Digest Editor's Note: Thanks for that great bit of history.
Most all readers of this Digest know that WUTCO and AT&T had a very
long history together over the years, but little tidbits such as yours
today are news to many folks. I also strongly recommend reading the
book by Oslin; you'll learn much about how things came to be as they
are. Without question, Ted Vail was the man who made AT&T what it is
today, or at least what it was for more than half a century.   PAT]

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

From: Todd Inch <toddi@fdsi1.ocsg.com>
Subject: Re: Pacific Bell Voice Mail Types
Date: Wed, 30 Mar 1994 09:48:43 PST


wjhalv1@pacbell.com writes:

>> Also, do Telco's provide voicemail to customers with their own PABX?

> Possible but unwieldy.  The PABX would have to have additional trunks
> back to the CO where the Telco's VM box is.

>> If so, how are the calls routed to the Voicemail equipment? I take it
>> the Telco will have a centralized VoiceMail node, and will route (divert) 

We have third party off-site voicemail (where each mailbox has it's
own real phone number but you can also select a different mailbox once
you're connected to the system) and use it in conjunction with our
PBX.

We use Centranet (GTE's brand name for "Centrex") to allow incoming
PBX calls to to be transferred to another number through the telco
(flash, dial number, hang up) without tying up our PBX phone lines.
We use this for forwarding to voicemail, to cell phones, and to our
recently split-off sister company.  Centranet also allows us to
forward our main number to the main voice mailbox after hours and
after the fourth ring.

Since we have an 800 number which rings in on our main number, this
works well for me to get my own voice mail from out of the area after
hours.  During business hours, I tell whoever answers in our office to
please transfer me to my voicemail after reading me any paper messages
first.

It really helps that we have system-wide speed dial numbers programmed
for each person's voicemail and the speed dial includes the required
"flash".  The only "kludge" is the PBX requires you to wait until it
has dialed the whole number before you hang up.  Fortunately the LCD
display shows the number as it is being dialed so you simply hang up
when you see all seven digits in the display.

Interestingly, when I call and voice mail answers, I never hear any
ringback tone -- I dial the number and almost immediately hear the
voice mail message.

I am looking into possibly getting our own in-house voicemail,
however, because (1) I think it would be cheaper than the service, and
(2) it would allow the message waiting lamps on the phone to light up,
and (3) an auto- attendant would allow fax/modem calls via our
existing 800 number and "inside" callers could bypass the receptionist
person with a backdoor number.

It's kinda silly -- we now get paper slips that say "check your
voicemail."

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

Date: Tue, 29 Mar 1994 12:11:50 -0500
From: goudreau@dg-rtp.dg.com (Bob Goudreau)
Subject: Re: Observations About Area Code Splits


LincMad@netcom.com (Linc Madison) writes:

> There are also some historical splits that look quite silly...
> In Massachusetts, 413 has fewer than one third the number of exchanges
> of either 617 or 508, and is one of the least populated NPAs.

Yes, but 413 and 617 were never split from one another at all; they
were both there from the start of the area code system.  In fact, I
remember an article in the Digest several years ago describing how 413
reportedly arrived a bit earlier than *that*, because a small region
in western MA was used by AT&T to prototype area codes, and 413 was
the code they tested it with.  Supposedly, that's how come such a
small and underpopulated region got one of the "best" area codes (by
using only 8 pulls, 413 is tied for sixth place for fewest-pulses-to-
dial), while Boston and the rest of MA ended up with 617.

That historical anomaly also explains why the original MA area code
boundary was drawn so far west, leaving 617 with two-thirds of the
land area and 80+% of the people in the state.  If things had been set
up more rationally, 413 probably should have extended at least as far
east as Worcester, and the need to split 617 (out of which 508 was
born in the late 1980s) could have been deferred for many years.


Bob Goudreau  Data General Corporation
goudreau@dg-rtp.dg.com 62 Alexander Drive 
+1 919 248 6231  Research Triangle Park, NC  27709, USA

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

Date: Tue, 29 Mar 94 12:46:15 EST
From: dwn@dwn.ccd.bnl.gov (Dave Niebuhr)
Subject: Re: Observations About Area Code Splits


In TELECOM Digest Volume 14 : Issue 153 LincMad@netcom.com (Linc
Madison) wrote:

> I was looking at David Esan's 1/15/94 NPA-NXX list and noticed quite a
> number of surprising numbers.  There were a couple of instances where
> I hope the answer is that a previously-effected split is not yet
> reflected in the number of exchanges shown for the old area code.  For
> example, 212 shows 639 exchanges, and 168 for 917.  I hope that the

Area code 917 is not a "true areacode" in the sense that it is restricted
to pagers, cell phones, and similar services, etc.

NYTel could have left the exchanges in 212/718 available and/or in use
after the overlay took affect.  What probably happened, and maybe
someone from NYTel/NYNEX who is more familiar with this could answer,
is that since there were available exchanges after the overlay, more
connections could be made for voice and data lines.

Or, Bellcore might not have deleted them from their V&H tapes.

I just can't see a company sitting around doing nothing with valuable
equipment.


Dave Niebuhr      Internet: dwn@dwn.ccd.bnl.gov (preferred)
                            niebuhr@bnl.gov / Bitnet: niebuhr@bnl
Senior Technical Specialist, Scientific Computing Facility
Brookhaven National Laboratory Upton, NY 11973  (516)-282-3093

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

Date: Wed, 30 Mar 1994 08:45:46 EST
From: padwad@psd.gs.com (Danny Padwa)
Subject: Re: Observations About Area Code Splits


Not sure about cellulars, but the 212-vs-917 split is still proceding
in terms of pagers.  While "new" numbers have been allocated out of
917 for well over a year (at least I have one much older than a year),
we are still just entering the "permissive" period for the switchover
for some of our older pagers.

I expect (not sure) that the above mentioned cellular provider will
soon be getting a surprise from NYTel (oops ... NYNEX).


Danny

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

From: king@wildebeest.cig.mot.com (Steven King, Software Archaeologist)
Subject: Re: AT&T Cellular Privacy System
Date: 30 Mar 1994 16:49:16 GMT
Organization: Motorola Cellular Infrastructure Group
Reply-To: king@wildebeest.cig.mot.com


I asked some questions regarding the AT&T Cellular Privacy System.  Mr.
Arneke kindly responded and indicated that I could post his response to
the Digest.  Thanks for the info, guys!


  From: darneke@attmail.com (David R Arneke)
  Date: 28 Mar 94 09:45:44 GMT
  Subject: Re: AT&T Cellular Privacy System

Here is a more complete answer to your message of last week regarding
the AT&T Cellular Privacy System. This comes from our cellular privacy
product manager, Ben Bratcher (214 280-9410).

1.  Is the scrambling technology simple inversion?

No.  The scrambling algorithm uses split-band frequency inversion,
translation of the upper band's frequencies, frequency dispersion of
both bands, time compression of both bands and independent time
displacement of the individual bands.

The combinations are determined by a key generator driven by a common
key that is negotiated for each privacy activation by using a public
key technique.  This is the strongest scrambling algorithm available
for handheld, transportable and mobile cellular subscriber equipment.

2. Is the signaling channel scrambled?  How about the blank-and-burst
signal sent on the voice channel to change power level or to do a
handoff?

Neither the signalling channel nor the inband signalling are
scrambled.  The Advanced Cellular Privacy System scrambles only the
user's audio.  However, the system is designed to maintain all
functions of the cellular telephone system without degradation.

3.  Is the SAT tone affected?

No.  The common channel interface of the cellular network is not
affected by the cellular privacy system.

4.  How does the mobile recognize that it's in a scrambler-capable
system?  How does the base site recognize that a mobile has a
scrambler attached?  Does the mobile scrambling unit recognize when
the mobile is roaming into an incompatible system and turn itself off?

The mobile system when activated sends a signal to the switch that
includes its part of the public key.  If the switch is scrambler-
capable and the user's electronic serial number (ESN) relates to a
privacy class of service mark, the switch will respond with its part
of the public key and privacy is established.  If there is no response
from the switch, the mobile system will return a fast busy, alerting
the user that privacy is not available and preventing communication
until the user releases the privacy request, indicating that
clear-only operation is acceptable.

The Mobile Switching Equipment (MSE) will first recognize that a user
has a privacy class of service from the relation of the ESN and the
home or visitor location register.  This causes the MSE to route the
call to the MSE-based scrambler equipment.  The MTSO Privacy Unit
(MSE-based scrambler equipment) then recognizes the initial signal
from the mobile subscriber and returns the confirmation.

If a user is roaming in a non-privacy capable system and tried to
initiate privacy, the mobile unit will not enter the privacy mode and
will alert the user.  If the mobile unit is operating in the privacy
mode and enters a non-privacy capable sysyem, the mobile unit also
will alert the user.  Every three seconds the mobile scrambler and the
switch scrambler exchange information.  After five failures (allowing
time for tunnels and fades), the mobile scrambler will return a fast
busy call and block communication.  The user can then choose to return
to clear mode.

5. Is the MTSO scrambler unit part of the base site or the switch?  If
it's part of the base site, can a scrambled call be handed off into a
cell with no scrambler unit attached?

The MTSO scrambler unit is attached to the MSE and therefore is always
available to cell sites associated with the MSE.  Through networking,
a MSE unit can continue privacy service as the mobile transits between
MTSOs.

6.  If there are no MTSO scrambler units available, does the
subscriber get any indication that the call is being sent in teh clear
rather than scrambled?

Yes, as described above.

7.  What is Ameritech charging for the service?

Confirm this number with Ameritech, but I believe it's $14 per month.

Thanks again for writing.  Feel free to pass this on to Telecom Digest
or anyone else who might be interested.


David Arneke
Media Relations Manager
AT&T Secure Communications Systems
david.arneke@att.com (!darneke on AT&T Mail)

                       ===================

Steven King <king@cig.mot.com> -- Motorola Cellular Infrastructure Group

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

From: dave@llondel.demon.co.uk (David Hough)
Subject: Re: Voice and Data Through PBX
Date: Wed, 30 Mar 1994 09:03:52 +0000


In article <telecom14.149.12@eecs.nwu.edu> Thomas Humphreys <trans-
omega@mv.MV.COM> writes:

> I have asked the question "Would you recommend running both voice and
> data (LAN) traffic through a PBX?" of 11 individuals. 4 said yes, 7
> said no.
 
> I am interested in what the readers of this newsgroup think about this
> issue.

I have to admit to some bias, because the company I work for is
developing a PABX which will do just this, as well as other features.

<hype on>

Basically, the intention is that the PABX is connected to the LAN and
can accept instructions from a PC on the LAN to dial numbers, answer
calls etc.  This allows you to use Windoze to pop up a phone directory
and click on a number to dial. The PC tells the PABX, the PABX dials
the number and kicks your keyphone into life in handsfree mode. When
the other end answers you can either pick up the phone handset or talk
handsfree. It doesn't take much of a leap from this to be able to
select a file and a destination and have the PC request the PABX to
set up an external data connection to the destination and transfer the
file. Even dial-on-demand routeing of individual network packets is
possible. Other options include the facility for a remote user using
ISDN to dial in and appear as an ethernet address on your LAN (CLI can
help with security here), which is ideal for the sales force who might
not have to visit the office quite so much.  

<hype off>

No we can't do all of that yet, but it is coming! It is about time the
telephone was properly integrated with everything else. After all,
digitized speech is only another 64kb data stream -- it has to be
switched the same as all other data streams.


Dave
G4WRW @ GB7WRW.#41.GBR.EU AX25     
dave@llondel.demon.co.uk  Internet 
g4wrw@g4wrw.ampr.org      Amprnet  

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

From: jim@isnpo1.pwss.gov.ab.ca (James Slupsky)
Subject: Re: Voice and Data Through PBX
Organization: Alberta PWSS Telecom
Date: Tue, 29 Mar 1994 21:12:57 GMT


In article <telecom14.149.12@eecs.nwu.edu>, Thomas Humphreys <trans-
omega@mv.MV.COM> writes:

> I have asked the question "Would you recommend running both voice and
> data (LAN) traffic through a PBX?" of 11 individuals. 4 said yes, 7
> said no.

> I am interested in what the readers of this newsgroup think about this
> issue.

In my opinion, there are much better products available for switching
LAN traffic than a PBX.  For voice, a PBX works great; for switched
data, a PBX also works great (although in some cases, a packet network
would be better).  But for LAN data, existing LAN networking
hardware/software costs less and is more mature.

If you desire to connect two lans, then ISDN links through a PBX may
also be an option.


Regards,

James Slupsky   jslupsky@pwss.gov.ab.ca

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

End of TELECOM Digest V14 #155
******************************


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