
From telecom-request@delta.eecs.nwu.edu  Fri Sep 29 13:53:42 1995
by
1995
13:53:42 -0400
telecomlist-outbound; Fri, 29 Sep 1995 09:27:21 -0500
1995
09:27:19 -0500
To: telecom@eecs.nwu.edu


TELECOM Digest     Fri, 29 Sep 95 09:27:00 CDT    Volume 15 : Issue 411

Inside This Issue:                           Editor: Patrick A. Townson

    UC Berkeley Short Courses on Communications (Harvey Stern)
    Re: Pac*Bell Lied, Do I Have Any Options? (Richard Eyre-Eagles)
    Re: Pac*Bell Lied, Do I Have Any Options? (Steven Lichter)
    Re: Pac*Bell Lied, Do I Have Any Options? (Curtis Wheeler)
    Re: Pac*Bell Lied, Do I Have Any Options? (Dave Harrison)
    Re: Hi-Speed via POTS (Tim Williams)
    Re: Eliminate Dialing Weirdnesses - We Can Save Lives (Toby Nixon)
    Re: Eliminate Dialing Weirdnesses - We Can Save Lives (Steve 
Cogorno)

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 America
On Line. It is also gatewayed to Usenet where it appears as the 
moderated
newsgroup 'comp.dcom.telecom'. 

Subscriptions are available 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: 500-677-1616
                        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.                                                 
*
************************************************************************
*

     In addition, TELECOM Digest receives a grant from Microsoft
     to assist with publication expenses. Editorial content in 
     the Digest is totally independent, and does not necessarily
     represent the views of Microsoft. 
     ------------------------------------------------------------

Finally, 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. A suggested donation of twenty dollars
per year per reader is considered appropriate. See our address above.

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.

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



U.C. Berkeley Continuing Education in Engineering Announces 4 Short
Courses on Broadband Communications, Wireless Networks

SONET/ATM-BASED BROADBAND NETWORKS: Systems, Architectures and
Designs  (November 29-December1, 1995)

It is widely accepted that future broadband networks will be based on
the SONET (Synchronous Optical Network) standards and the ATM
(Asynchronous transfer Mode) technique.  This course is an in-depth
examination of the fundamental concepts and the implementation issues
for development of future high-speed networks.  Topics include:
Broadband ISDN Transfer Protocol, high speed computer/network
interface (HiPPI), ATM switch architectures, ATM network
congestion/flow control, VLSI designs in SONET/ATM networks.  This
course is intended for engineers who are currently active or
anticipate future involvement in this field.

Lecturer: H. Jonathan Chao, Ph.D., Associate Professor, Brooklyn
Polytechnic University.  Dr. Chao holds more than a dozen patents and
has authored over 40 technical publications in the areas of ATM
switches, high-speed computer communications, and congestion/flow
control in ATM networks.

MODERN TELECOMMUNICATIONS: Wide Area Networks, Personal Communication
Systems, Network Management and Control, and Multimedia Applications
(November 2-3, 1995)

This course is designed as a gentle but comprehensive overview of
telecommunications including current status and future directions.
This course traces the evolution of telecommunications, starting from
its voice roots and progressing through local, metropolitan, and wide
area networks, narrowband ISDN, asynchronous transfer mode, broadband
ISDN, satellite systems, optical communications, cellular radio,
personal communication systems, all-optical networks, and multimedia
services.

Lecturer: Anthony S. Acampora, Ph.D., Professor, Electrical
Engineering, Columbia University.  He is Director, Center for
Telecommunications Research. He became a professor following a 20 year
career at AT&T Bell Laboratories, is an IEEE Fellow, and is a former
member of the IEEE Communications Society Board of Governors.

NETWORKS FOR DIGITAL WIRELESS ACCESS: Cellular, Voice, Data, Packet,
and Personal Communication Systems (November 8-10, 1995)

This comprehensive course is focused on the principles, technologies,
system architectures, standards, and market forces driving wireless
access.  At the core of this course are the cellular/microcellular/
frequency reuse concepts needed to enable adequate wireless access
capacity for Personal Communication Services (PCS).  Presented are
both the physical-level issues associated with wireless access and the
network-level issues arising from the inherent mobility of the
subscriber. Standards are fully treated including GSM (TDMA), IS-54
(North American TDMA), IS-95 (CDMA), CT2, DCT 900/CT3, IEEE 802.11,
DCS 1800, and Iridium.  Emerging concepts for wireless ATM are also
developed.  This course is intended for engineers who are currently
active or anticipate future involvement in this field.

Lecturer: Anthony S. Acampora, Ph.D., Professor, Electrical
Engineering, Columbia University.  He is Director, Center for
Telecommunications Research. He became a professor following a 20 year
career at AT&T Bell Laboratories, is an IEEE Fellow, and is a former
member of the IEEE Communications Society Board of Governors.

ATM DATA COMMUNICATIONS NETWORKS: Internetworking, Signaling and
Network Management (November 27-28, 1995)

This short course examines the key issues involved in designing and
implementing high-performance local and wide area networks.  Topics
include: technology drivers, data protocols, signaling, network
management, internetworking and applications.

Lecturer: William E. Stephens, Ph.D., is the Head of the Wireless and
ATM Networking Group at the David Sarnoff Research Center.  Prior to
this he was Director, High-Speed Switching and Storage Technology
Group, Applied Research, Bellcore.  Dr. Stephens has over 40
publications and one patent in the field of optical communications.
He has served on several technical program committees, including IEEE
GLOBECOM and the IEEE Electronic Components Technology Conference, and
has served as Guest Editor for the IEEE Journal on Selected Areas in
Communications.

For more information (complete course descriptions, outlines,
instructor bios, etc.) send your postal address or fax to:

Harvey Stern
or Loretta Lindley
U.C. Berkeley Extension/Southbay
800 El Camino Real Ste. 150
Menlo Park, CA 94025
Tel: (415) 323-8141
Fax: (415) 323-1438
email: southbay@garnet.berkeley.edu 

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



Christopher Ambler (chris@ivanova.punk.net) wrote:

> But I got a firm commitment from the business office ...

> Do I have any recourse here? We need more lines, and this is getting
> very frustrating.

I know your situation.  I used to work for Pacific Bell in the Residence 
Business Office.  I worked with BBS's.

Unforutnately, us who want more than six lines are really considered
as 'excessive users'.  There was a time when they tried to force all
of the BBSs to business service.

In a residential area, there is at least one cable pair reserved for 
each 
residential unit (this includes apartments and 'rear houses').  This is 
caled CT'ing the pairs.  

Once you hit your max (which you have), that's pretty much it.  You have 
a few choices on where to go from here:

1) Pay the construction charges.  If your operation is long term, it may 
be a huge outlay but it may pay-off in the future.

2) Switch your lines to business and consider having your lines brought 
on a digital entrance facility.  In this configuration, your lines are 
brought in on a T-1.  You will need to purchase 'channel banks' so the 
T-1 lines can be converted back to analog so you can use your existing 
modems.  Each T-1 only takes 2 pairs and can hold up to -24- lines. 
When I worked for Pacific, I tried to get digital entrance facilities 
approved for residence, but ol' Paccy*Bell did not budge.

3) Primary Rate ISDN.  23B and 1D channel on your first circuit, 24B on 
each additional.  You can have your internet connection ride one of 
these 
channels and have your users ride on the other 22.  

4) Pacific Bell's public packet switching.  You can have a high speed 
connection to Pacific's network and other users can call a Pacific Bell 
port number and type your 'address' then they will be connected to you.  
There are a few boards using this.  

Unfortunately, Pacific Bell has tolarence for it's high user residential 
customers but they will not bend over backwards for them.  Maybe if you 
ordered a 100 line Centrex and paid all the installation charges up 
front,  you may see some movement in the vertabrae.  

I now live in US West area and I am being threatened with construction 
charges for anything over six lines, even though the F-2 going down my 
street has 15 pairs available (I currently have 2).  

Good-Luck ... please E-mail me if I can be of any help.

BTW, are you in Northern or Southern CA?


Richard Eyre-Eagles, KJ7MU 
Tempe, Arizona             

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



I guess PacBell could look at your operation as a business, even though 
you say it is not. In fact you are all paying for a common point to 
access The Internet. Since you live in a non-business area they might 
not 
have enough pairs to supply such a venture. Though they did give you a 
firm
ok, they may have an out. I guess you could go to the PUC, but then the 
PUC in their very strange ways may say that you are in fact a busineness 
then your rates will go through the roof. I guess PacBell feels that 
since the lines are used just for incoming they are not making any oney 
other then the monthly service charge. The PUC is really your only 
option 
and it could blow up in you face.


The above are my ideas and have nothing to do with whoever my employer 
is.
SysOp Apple Elite II and OggNet Hub (909)359-5338 2400/14.4 24 hours,
Home of GBBS/LLUCE Support for the Apple II. 
slichte@cello.gina.calstate.edu

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



chris@ivanova.punk.net (Christopher Ambler) wrote:

> We have 26 lines (residential POTS) and 1 ISDN line into our house. 
(For
> the curious, we have an internet cooperative amongst 20 people, ISDN
> carries internet to my house, and then 20 modems take it all over town
> to the members).

[out of pairs story snipped]

> Today (a day before the install date), an engineer came out and was
> rather rude with me, telling me that there's been a block placed on my
> address, such that we can have no more lines. He said we can pay
> upwards of $10,000 (ten thousand dollars!) to have the area rewired.

> But I got a firm commitment from the business office ...

> Do I have any recourse here? We need more lines, and this is getting
> very frustrating.

Your recourse would be the PUC.  I don't work in the common carrier
business so I don't know the facts -- but I would be prepared to hear
that Pac Bell may only be obligated to provided a certain number of
lines to a residence.

Perhaps your cooperative needs to consider an alterative service.  If 
you 
need that much service you may be justifying more digital.  

Will the cable facilities in most residential areas support a T carrier 
into your living room?  Provisioning and equipment might have apparent 
high initial cost but your co-op would probably benefit in the long 
term. 
Sounds like it's time to make some business decisions.
  

Curtis Wheeler - Pleasanton, CA

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



Pac Bell is well within the tariff, which covers "Special Construction
Charges" for situations like yours.  When they design the outside
plant, they plan for x number of lines per residence.  You were lucky
to get that many lines in the first place.  

If you want to invest in a channel bank, you can have 24 lines come
in on four wires (a T1).  Or, you can simply move to a commercial office
where having 50 lines would be no problem.

And by the way, co-operative or not, you should be paying for business
service. You can't argue "we're non profit"... so is the Red Cross and
they pay for the proper service.

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



Robert Ricketts <rkr@pel.com> wrote:

> Greetings. I'm looking for a couple of boxes that does the following:


>           A       B         C         D        E        (see below)
>      |         |     |             |     |           |
>      |         |     |             |     |           |
>      |         |     |             |     |           |
>      |         |     |             |     |           |

>                 -----  28.8 Kbps    -----
>       57.6 Kbps |  b|---------------|b  | 57.6 Kbps
>   DTE ----------|a  |  28.8 Kbps    |  a|----------- DTE
>                 |  b|---------------|b  |
>                 -----               -----

>     A = Serial line, 115.2 kbps
>     B = Box that splits a single 'a' channel into two simultaneous
>         'b' channels.
>     C = Four plain-jane 28.8 kbps modems.  One on each end of two
>         POTS lines.
>     D = Box that merges two simultaneous 'b' channels back into a
>         single 'a' channel.  (Same box used for B)
>     E = Serial line, 115.2 kbps

>  Connection is TWS

>  The DTE would be see the appearance of a plain-jane modem.  Perhaps 
with
>  special dialing commands to cause the component modems to place their
>  respective calls.  A and E appear as traditional DCE.

>  The beauty of this is high speed through-put using POTS.  I don't 
have to
>  even settle for two modems.  Perhaps three or four for uncommpressed 
115.2
>  thru-put, or more when compressed using special serial ports, e.g.  
230.4
>  kbps.  Each box would reassemble arriving packets to the original 
sequence.

>  Sort of a reverse mux.  Anyone ever seen such a thing?

This is called load-balancing, and many opearting systems (unix based)
allow you to do this completely software based. You can have say 15
28.8 modems all hooked up, and use them together to form a high-speed
connection. Try using Linux or FreeBSD.

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



In Telecom Digest V15 #405, rlm@netcom.com (Robert McMillin) wrote:

>> Our telephone systems should be straightforward enough that any child
>> capable of remembering their phone number can be taught how to pick 
up
>> any phone and dial their home phone number or 911.

> Mr. Yost goes on to suggest that "We should work toward a standard


            

> that would allow a child to dial simply 1 + area code + number from
> any phone ... and get connected to their home."

> By this approach, we should make the world completely and utterly safe
> for four-year-olds.  This is the rallying cry currently used as a
> justification for censoring adults on the Internet.  Adults use cars,
> airplanes, lathes, pornography, and slaughterhouses, all of which are
> patently unsafe (or at least, unwise) for four-year-old operation.
> Not everything can -- or should -- be made child-safe.

But in this case, adding some consistency, simplicity, and sanity to
the dialing plan in North America would help a lot more than
four-year-olds. It would, in fact, go a long way toward making it
possible to reliably dial calls from your computer, wherever you might
be. We all know that computers are actually dumber than four-year-olds, 
right? This is particularly true when it comes to dialing. Your
computer can't read the template around the phone dial, the card by
the phone, or the front of the phone book. There's no way to connect
your computer to the phone network, and have it ask the network "how
do I dial calls from here?", or to dial "0" and ask the operator for
help.  It can't automatically know whether or not to dial 9 before
some calls, 8 before others, and nothing on yet others. It can't
figure out how to dial 011 or 00 before country codes, or 1 or 0 or
whatever before city codes. Even within a single country, you have
cases where numbers in the same area code as you have to be dialed
sometimes with 7 digits, sometimes with 10, and sometimes with 11, and
there's no way to ask the network which is which; all you can do is
trial-and-error. And the error doesn't have any sort of machine-
detectable 
tone; it's just an undecodable voice prompt!

Some people have thought of having a database on the net that anyone 
could connect to and download dialing rules on a per-exchange basis 
(which area codes and exchanges are "same area local", which are "same 
area toll", which "foreign area local", etc.), and the part of the 
number and prefixes that need to be dialed for each category. If we had 
commitments from all local exchange carriers to build and maintain this 
database, it might be possible. But I don't think even that would be 
good enough. Many LECs have different "subscription" options that let 
individual users expand their local calling area on a line-by-line 
basis by paying a little extra each month;  even if the database 
included all of these options, there's no way for a computer to query 
the network and find out which options are enabled on a given line! Is 
software going to ask the user to dig out their phone book and latest 
phone bill, find the codes that identifying optional local calling area 
plans, and type those into the computer so that it knows how to dial 
calls? You end up, whatever you do, with the end user needing to do a 
bunch of programming or configuration of their computerized dialing 
software, and that assumes that they can even find out the current
information.

So, why SHOULDN'T the phone network be designed so that computers can 
be connected to the network ANYWHERE and be permitted to input a 
fully-qualified international number (including country code) and have 
the NETWORK figure out how to route the call, instead of the computer 
needing to be pre-programmed to know exactly which subset of the phone 
number needs to be dialed, along with whatever prefixes are needed?  
All we need to do is define some sort of single, nationwide (even 
worldwide!), standard prefix that says "what follows is a country code 
and nationally-significant number; YOU figure out how to connect me".  
So what if it takes a few more digits to dial *00,12068828080 when, if 
it was local to me, it could have been dialed as just "8828080" -- 
those "extra" six digits only took half a second to dial, and I didn't 
have to make two or three failed call attempts to find the right digit 
sequence! This ought to be implementable on PBXes just as easily as on 
COs.

We need to get the state public utility commissions out of the business 
of dictating dialing procedures, and overcome the fiction that dialing 
a "1" before a number means "I have to pay extra for this call". We 
need a national consensus among LECs and PBX vendors on what this 
prefix should be that allows a fully-qualified international phone 
number to follow. Mr. Yost's point about children being unable to 
figure out how to dial in an emergency situation is a good one to wake 
up regulators, legislators, and telephone system designers who 
otherwise might not pay attention to the problems caused by confusion 
in the national dialing plan. Once awareness of the problem is raised, 
however, I would expect the primary motivation for finding a solution 
would be to facilitate shipping and installing shrink-wrapped software 
with preloaded phone numbers, distribution of phone numbers and dialing 
directories over the Internet that can be dialed anywhere, 
simplification of dialing configuration for travelers with computers.


Toby Nixon
Program Manager - Windows Telephony
Microsoft Corporation

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



Clifton T. Sharp said:

> In article <telecom15.394.5@eecs.nwu.edu> johnl@iecc.com (John Levine)
> writes:

>> Call Trace serves this function now. It does what caller-ID is
>> frequently misrepresented as doing, collecting the calling number of 
a
>> call that you need to report to the cops.

> What can Call Trace get that CNID wouldn't report accurately? The only
> thing that I've heard about inaccurate CNID so far regards outdial
> trunks, which would presumably be reported the same way to Call Trace.

Well for one thing, the CID can be blocked.  Call Trace cannot.  As
somone else pointed out, Call Trace is only good within the LATA
(because it relies upon SS7), but I believe that this will be changing
when the December FCC Caller-ID IXC thing goes into effect.

But, I think it's a major scam that the LECs charge such high prices
for Call Trace (PacBell charges $5/trace).  There is a lot less work
involved for them than setting a trap on the line - they should make it
free or at the most $1 to discourage abuse.


Steve  cogorno@netcom.com

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

End of TELECOM Digest V15 #411
******************************

                                 
