TELECOM Digest     Mon, 2 May 94 15:20:00 CDT    Volume 14 : Issue 194

Inside This Issue:                          Editor: Patrick A. Townson

    Two Communication Courses (Richard V. Tsina)
    Senior Telecom Engineer Wanted at Intel/Oregon (Mike Gore)
    Open Position SWE / ISDN TCP/IP Unix Networking Agent SFSYS (Hal Kinney)
    Re: DID Loophole or I'm Screwed Up? (Jonathan Loo)
    Re: DID, PBX and University Phones, SL-100 (Zafar Khalid)
    Re: GSM and Airbags (Bill Tighe)
    New BBS List to Save Money (Stu Whitmore)
    Re: Help: Programming Motorola 550 and Fujitsu Commander (puma@netcom.com)
    Re: Help: Programming Motorola 550 and Fujitsu Commander (John Barcomb)
    Re: E1 Help Wanted (Marc Chatel)
    Re: Unwelcome AT&T "Feature" (Jay Hennigan)
    Re: Unwelcome AT&T "Feature" (Jonathan Loo)

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: rtsina1@uclink.berkeley.edu (Richard V Tsina)
Subject: Two Communication Courses
Date: 2 May 1994 19:15:51 GMT
Organization: University of California, Berkeley


U.C. BERKELEY

Continuing Education in Engineering Announces Two Short Courses on
Communication Technology:

1.   WIRELESS COMMUNICATION NETWORKS
     (July 26-27, 1994)
     
     There are technical bottlenecks to developing a ubiquitous
wireless multimedia environment: the capacity of the radio link, its
unreliability due to the adverse multipath propagation channel, and
severe interference from other channels.

     This course covers the principles and fundamental concepts
engineers need to tackle these limitations (e.g., a thorough treatment
of channel impairments such as fading and multipath dispersion and
their effect on link and network performance).  Topics include:
Introduction to Wireless Channels, Cellular Telephone Networks, Analog
and Digital Transmission and Wireless Data Networks.  Comprehensive
course notes will be provided.

Lecturer: JEAN-PAUL M.G. LINNARTZ, Ph.D., Assistant Professor of
Electrical Engineering and Computer Sciences, University of
California, Berkeley.  His work on traffic analysis in mobile radio
networks received the Veder Prize, an innovative research in
telecommunications award in the Netherlands.  At Berkeley he works on
communications for intelligent vehicle highway systems and multimedia
communications.  Professor Linnartz is the author of numerous
publications and the book "Narrow Land-Mobile Radio Networks" (Artech
House, 1993), the text for the course.

2.   COMMUNICATION NETWORKS: FROM FDDI TO ATM
     (August 9-10), 1994)    
 
    This course provides an overview of the operating principles and
design guidelines for communication networks, and includes a
description of the popular current networks and a discussion of major
industry trends.  Topics include: History and Operating Principles,
Open System Interconnection, Overview of High-Speed Networks, Physical
Layer, Switching, Trends in Data Networks (FDDI, DQDB, Frame Relay,
SMDS), Trends in Telecommunication Networks (SONET, Fiber to the home,
ISDN, Intelligent Networks, ATM) , Topological Design of Networks,
Control of ATM Networks.  Comprehensive course notes will be provided.

Lecturers:

PRAVIN VARAIYA, Ph.D., Professor of Electrical Engineering and
Computer Sciences, University of California, Berkeley.  At Berkeley he
works on stochastic systems, communication networks, power systems and
urban economics. He is the author of "Stochastic Systems: Estimation,
Identification, and Adaptive Control" (Prentice-Hall, 1986) and
coeditor of "Discrete Event Systems: Models and Applications"
(Springer, 1988).  He is a fellow of the IEEE.

JEAN WALRAND, Ph.D., Professor of Electrical Engineering and Computer
Sciences, University of California, Berkeley.  He is the author of "An
Introduction to Queuing Networks" (Prentice-Hall, 1988) and
"Communication Networks: A First Course" (Irwin/Aksen, 1991).

For more information (complete course descriptions, outlines,
instructor bios, etc.,) contact:

Richard Tsina
U.C. Berkeley Extension
Continuing Education in Engineering
2223 Fulton St.
Berkeley, CA 94720
Tel: (510) 642-4151
Fax: (510) 643-8683
email:  course@garnet.berkeley.edu

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

From: mike_gore@ccm.hf.intel.com
Subject: Senior Telecom Engineer Wanted at Intel/Oregon
Organization: Multimedia Software Technology Group
Date: Mon, 02 May 1994 11:09:05 GMT


                     SR TELECOM ENGINEER

Intels Oregon Information Technology Group is looking for a senior
Telecom engineer to create an Enterprise-wide Plan for the deployment
and support of Network and Systems technologies, focusing on the
Operational Infastructure Requirements. Individual will work with
Central Network and LAN Systems engineering staffs and site IT
Network. Candidates should have knowledge of 802.3,FDDI, and ATM
standards. Knowledge of TCP/IP,IPX,RIP,OSPF. In addition you should
have experience any Cabletron, Synoptics, Cisco, and Wellfleet
hardware. Must use network analyzers, and SNMP management Spectrum,
HP-Openview, SunNet Manager or Netview 6000. BA and 6 to 9 yrs
experience in designing and implementing mul-protocol enterprise
routed networks.. This position includes great salary, bonuses, stock
options, 401K, and excellent relocation package. 

If you are interested:
EMAIL: mike_gore@ccm.hf.intel.com 
Or you may call 602-554-4485

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

From: halkin@netcom.com (Hal Kinney)
Subject: Open Position SWE / ISDN TCP/IP Unix Networking Agent SFSYS
Organization: Netcom Online Communications Services (408-241-9760 login:
guest)
Date: Mon, 02 May 1994 00:24:58 GMT


  Position: SWE Software Engineer   
  Skills: C programming - Heavy Communications knowledge         

  Minimum Industry Experience: Three years experience. College projects 
  do NOT qualify.
    
  Location: Palo Alto Ca.              

  Start Date: ASAP   

  Pay Rate: Commensurate with experience              

  Length: Contract to hire          

  Student Visa ok ?: No No No No            
  H1 Visa ok ?: For the right candidate  

Comments : Should be very strong writing device drivers in the
communications environment. Should be experienced with ISDN, TCP/IP,
X.25, POTS, Unix, Routers and Bridges, PC's.  Programming devices in
the communications / network environment.

Contract to hire or immediate hire for the right engineer.

FAX/email resume and/or lets talk.


San Francisco Systems, Inc.   Contact: Hal Kinney     halkin@netcom.com
110 Sutter St. Suite 701                            Voice: 415.982.3500
San Francisco, Ca. 94104           FAX: 415.982.6013 (high res. please)

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

Date: Mon, 02 May 1994 01:30:09 -0400
From: Jonathan <jdl@wam.umd.edu>
Subject: Re: DID Loophole or I'm Screwed up?


TELECOM Digest Editor noted:

> TELECOM Digest Editor's Note: Not only asked to correct the problem,
> but in some instances if telco really wants to get tough about it they
> may choose to back-bill an estimated amount lost on completed calls
> which went unsupervised. Illinois Bell found a company here in Chicago
> deliberatly playing games like that and back-billed them a
> half-million dollars covering calls over a five year period. The
> company protested of course, but all the facts pointed to them doing
> it on purpose as toll-avoidance; they were slow to answer their phones
> because they did not want to hire the help needed to do so promptly
> and they were playing a tape recorded music on hold 'all positions
> busy please wait for an available agent' message to their callers for
> five or ten minutes at a time. Their customers squawked about the cost
> of *their* calls as a result so the company gerry-rigged the system to
> not supervise until they got ready to handle the call.  IBT said it
> wasn't *their* problem ... they wanted their money! Instead of going
> back to each individual caller (thousands of them) to collect the
> couple dollars each of them would have paid had they been supervised
> properly, telco told the company since they pulled this stunt they
> could pay for it instead ... or get sued with the resulting publicity,
> etc.  Telco did not get all they asked for, but they collected a nice
> chunk of it. So be careful about playing games with supervision. If
> telco wants to do so, they'll work you over good to show who is boss.

Sounds pretty ingenious to me.  I would like to note a few things:

1.  No meaningful conversation occurred until after the company turned
supervision on.

2.  The telephone company could have been nicer about the whole thing.
Instead of waiting for five years and then billing for half a million
dollars, why not send a warning to the company within one month and
then bill them shortly thereafter?  There must be a way for the
telephone company to automatically detect this kind of stunt.
Furthermore, the company that received the calls may have assumed that
the telephone company would have objected immediately had its stunt
been illegal.  After all, nobody lets the phone ring for five minutes
on a routine basis.  If the telephone company had been doing its
homework, then it should have noticed calls ringing for several
minutes, in- vestigated the possible trouble, referred it to the
business office, and told the company to stop, quickly.

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

From: clipper.robadome.com!khalid@pmail.com (Zafar Khalid)
Subject: Re: DID, PBX and University Phones, SL-100
Date: 02 May 1994 17:03:03 GMT
Organization: ROLM - A Siemens Company
Reply-To: clipper.robadome.com!khalid@pmail.com


In article 13@eecs.nwu.edu, jay@coyote.rain.org (Jay Hennigan) writes:

> In article <telecom14.186.3@eecs.nwu.edu> canadian@leland.stanford.edu
> writes:

>> Phone Question for those in the know.(I am not one of them, so please
>> reply in layperson lingo if possible. :-))

>> I am the Business Manager of the Student newspaper, the Stanford
>> Daily.  We are independent from the university, and are running a
>> very tight budget.  We pay alot each month to be connected to our
>> phone service and have no choice but to use the university phone
>> service.  We are currently we are being charged anywhere from $28.50
>> to $37.50 per month for each phone (which we own) plus $12.50 per
>> phone for an expanded local calling area ranging from San Francisco 
>> to San Jose and parts of the East Bay.

>> The Daily intends to convert its current incoming 32 line mixed ET and
>> single-line set configuration to a set of 16 analog DID wink-start
>> trunks mapped to our current 32 numbers. We will be installing a
>> DID-ready PBX, station lines, and PBX telephones on our premises.

> Unless you get an extraordinary amount of incoming traffic, 16 DID
> trunks for 32 numbers is gross overkill.  Six to eight trunks are far
> more realistic.  Also, keep in mind that DID trunks are usually
> one-way incoming, so you'll need some outbound and/or two-way
> ground-start trunks as well.     ....

I agree that 16 DID lines are overkill, while six to eight are very
realistic.  I would further recommend that instead of DID lines, you
get ordinary loop start or ground start lines arranged in a hunt
group, and route all calls to a Auto-Attendant system behind your PBX.
Auto-attendant can redirect incoming calls and also could be used as
voiceMail system. These systems are in $3000-15000 price range
depending upon the vendor. For example: Centigram, ROLM PhoneMail,
ActiveVoice, Octel SmoothOperator are worth looking into.

Cheers.

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

From: bill@noller.com (Bill Tighe)
Subject: Re: GSM and Airbags
Date: 2 May 94 10:24:1 GMT


gws@gwssun.cb.att.com (Gary Sanders @ AT&T Bell Labs, Columbus Ohio.)
once wrote ...

> In article <telecom14.177.7@eecs.nwu.edu>, Stewart Fist <100033.2145@
> CompuServe.COM> wrote:

>> I've just received by fax a photocopy of a story from the {Guardian
>> Weekly} (UK) dated April 3.

>> It is headlined "Mobile phone set off airbag" and the story is about a
>> couple of instances where (it is claimed) GSM handsets have set off

     ...

> Yes but think about it; what is a switch but a couple of contacts? Add
> a liitle bit of dirt and gunk and you now have a diode. What can you
> you do with a diode -- you can detect radio signals. You now have an
> RF switch.

I have a brochure from Chrysler with a photo of one of their cars
undergoing RF testing.  The car is on a turntable in an anechoic room
with a _huge_ Yagi-like antenna pointed at it.  The test stated that
all the cars systems are tested in every conceivable RF environment.
It looks like they spend a lot of money to make ambient RF a
nonproblem.
  
I know RF has been a problem in the past; my 83 Volvo drops out of
cruise control when near a CB transmitter.  Some Audis in the early
80s would respond to RF by having the cruise control go to full
throttle while the ABS disabled the brakes!

I think the car makers have learned their lesson and now test their
cars for use with cellular phones and other transmitting products.
Hackers with multi-kW linears may still have problems.


Bill Tighe                 Noller Communications, Inc.
Email:  bill@noller.com    1250 Holm Road
Phone:  707-778-0571       Petaluma, CA 94954-1172
FAX:    707-778-0235

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

Date: Mon, 02 May 1994 13:40:47 -0700
From: whitmore@tahoma.cwu.edu (Rattlesnake Stu)
Subject: New BBS List to Save Money
Organization: Central Washington University


I have decided to compile a list of BBSs that use Sprint for a long
distance carrier for outbound long distance.  The sole purpose for
this is to save money through Sprint's automatic discount on
Sprint-to-Sprint calls.

If you run a BBS and your long distance carrier (on at least one line)
is Sprint, feel free to fill out the information below and e-mail it
to me.  The list will be published in two forms: The terse form will
be limited to one line per BBS, and the verbose form will include a
second line for comments.

Please feel free to pass this along to other SysOps so that a
comprehensive list can be established.  Let it be known upfront that I
do not work for Sprint and am in no way affiliated with Sprint other
than as a customer.  The list will not be sold, but will be
distributed freely.  There is little in it for me other than the
savings, which I hope to pass along to other Sprint customers.  I
fully encourage customers of other carriers that offer similar
automatic discounts like Sprint's to start similar lists.

The form for the data is:

Data needed:                               Example:
------------                               --------
System name: [_______________________]     [Hibernation BBS________]
Primary #:   [___-____-_____]              [628-433-9812]
City:        [___________]                 [Cyberville_]
State:       [__]                          [IT]
SysOp:       [_______________________]     [Big Bear_______________]
# Nodes:     [__]                          [1_]

Free-form Comments:
[______________________________________________________________________]

(Example:
[This is a BBS for beekeepers and bear watchers.__(NOT A REAL BBS!)____] )

E-mail to whitmore@tahoma.cwu.edu or 71221.1737@compuserve.com.  These
addresses are temporary - send a note of inquiry after 5/15/94 to either
of these addresses for an address update.


Stuart Whitmore
whitmore@tahoma.cwu.edu
Standard disclaimers apply  (no implied representation of CWU)

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

From: puma@netcom.com (puma)
Subject: Re: Help: Programming Motorola 550 and Fujitsu Commander
Date: Mon, 02 May 1994 21:40:47 GMT


In article <telecom14.182.7@eecs.nwu.edu>, Lance Ware <lware@voxel.com> 
wrote:

> I need help with programming these two cell phones. Specifically I
> need to program the phone numbers, and get the ESN so that I may have
> them both put on the same phone number.

> This is legitimate, I am not interested in going to jail for many
> years!

You may consider it legitimate, but it's a violation of federal
regulations and also contrary to your contract with the service
provider.  Not that folks haven't done it in the past, you understand,
but it's against the rules.  If you, at some point, have both phones
powered up at the same time, the service provider is likely to detect
it and lock you out.

The ESN's are supposed to be a permanent part of the phone, and not
changeable without replacing the ROM.  I've heard, though, that some
are capable of being changed in the setup.  Also, Motorola for one has
a special version of their phones with loadable ESN so that they can
provide a loaner in service situations.  Normally the setup only
allows changing the telephone number and other setup info, not the
ESN.


puma@netcom.com

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

From: uswnvg!uswnvg.com!jbarcom@uunet.UU.NET (John Barcomb)
Subject: Re: Help: Programming Motorola 550 and Fujitsu Commander
Date: 02 May 94 17:51:00 GMT


Lance Ware (lware@voxel.com) wrote:

> I need help with programming these two cell phones. Specifically I
> need to program the phone numbers, and get the ESN so that I may have
> them both put on the same phone number.

> This is legitimate, I am not interested in going to jail for many
> years!

The ESN of your Motorola phone will be listed on the phone in HEX,
starting with an 8.  I'm not too sure about your Fujitsu.  My
experience with having two cellular phones programmed with the same
number is that both WILL ring, but no matter which one is answered,
the call will drop right away.  Can't explain it, it just happens.

 
John

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

From: chatel_m%annecy.dnet.dec.com@decuk.uvo.dec.com (Marc Chatel)
Subject: Re: E1 Help Wanted
Date: 2 MAY 94 08:56:39 HEC
Organization: Digital Equipment Corporation


In article <telecom14.185.12@eecs.nwu.edu>, jwl@netcom.com (Jack W.
Lix) writes:

> I need some information about "real world" E1 usage.  Does timeslot 16
> (normally used for signalling) ever get used for data in point to
> point usage.  I also understand some satellite transceivers use an E1
> interface.  Would they also reserve timeslot 16??  If so, whats the
> point??

Hmmm ... where do I start? E1 (described in ITU-TS G.703) is a
2.048Mbps clocking standard (unlike 1.544Mbps T1). All the E1
implementations I have seen so far use HDB3 for coding. This means
that, unlike some forms of T1, E1 is always (to my knowledge)
data-insensitive. That is, you can send as many zeroes or ones in
succession on an E1 link without losing sync.

How is E1 used in practice in the field for data usage?

1) Most common: Keep timeslot 0 for framing as per G.703 and use
timeslots 1 to 31 (including timeslot 16) for data. Effective
bandwidth available to the access device: 1.984 Mbps. Useful because
the carrier can monitor timeslot 0 and detect if the link is down at
the same time as the user (more or less) ...

2) Next most common: If the devices at both ends can create their own
framing without requiring G.703 framing, and if the PTT providing the
link is prepared for it (no intermediate devices on the line that
expect G.703-compliant timeslot 0), you can use timeslots 0 to 31 for
data. Effective bandwidth available to the access device: 2.048 Mbps.

You get more bandwidth, but the carrier cannot tell if the user
end-to-end link works or not, until a loopback is inserted, of
course ...

3) Fractional: Just like for T1, some administrations offer lower link
speeds (any N x 64 speed) by providing the user a 2.048 Mbps G.703
access with only some of the timeslots being transported to the far
end. There is no standard among PTTs and carriers about what timeslots
are used in such a case. This is more difficult to get in some
European countries than others, believe me.

The only case where timeslot 16 has a special meaning is when E1 is
used to transport standard voice traffic. In that case, timeslot 16
(as per G.704, G.732, etc.) is used to transport the signalling for
the voice channels being carried in timeslots 1-15 and 17-31.

Two signalling standards are defined for E1: CAS (a 4-bit value per
voice channel is transmitted 500 times per second) and CCS (timeslot
16 is used as a straight 64Kbps data channel, usually carrying CCS-7
style signalling).

In the hope this helps,


Marc Chatel    consultant
currently at: Digital Equipment France
Annecy, France

e-mail: chatel_m@annecy.enet.dec.com
        mchatel@pax.eunet.ch        (permanent)

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

From: jay@coyote.rain.org (Jay Hennigan)
Subject: Re: Unwelcome AT&T "Feature"
Date: 02 May 1994 11:02:39 -0700
Organization: Regional Access Information Network (RAIN)


[In reference to AT&T disconnecting unanswered direct-dial calls]

> [TELECOM Digest Editor's Note: I'll tell you why AT&T adopted that stance.
> Radio talk show host Larry King was in the habit of helping his callers
> avoid toll charges by telling them, "when you call us, just let it ring,
> we will answer you when it is your turn to be on the air ..." While most
> talk shows answer and screen your call, then leave you on hold upwards
> of 30-45 minutes waiting for your chance to spill your bile (on your 
> nickle, I might add ... very few are willing to provide an 800 number
> for you to camp out on at their expense), 

"The only information highway you'll ever need" does.  1-800-282-2882.

> King's thing was to have all his bells turned off and let the lights
> on his phone wink instead. That way the caller did not have to pay and
> neither did King. AT&T got stuck with the cost instead of having their
> circuits tied up in a non-revenue position for the several hours King
> is on the air. AT&T finally got tired of being the straight man for
> King's routine and started cutting off his unanswered calls after a
> couple minutes.

This seems a bit hard to swallow.  How many incoming trunks does Larry
King have?  Maybe a dozen.  Maybe two dozen.  How many million calls a
day does AT&T carry?  So ten or twenty people listen to ringing for an
hour or so.  Are you suggesting that this is going to have enough
impact on AT&T's revenue that they are going to re-engineer their
network to prevent it?  Thousands more get busy signals.  If AT&T
would improve their call processing time by one second, they would
free up the thousands of busy signal circuits one second sooner (and
AT&T indeed has very fast setup times).

> King's response was predictable: when he found out what AT&T was doing
> he blasted them over the air and told all his callers to start calling
> him using Sprint's 10333 code instead. AT&T's response:  Good!  Let him
> abuse Sprint instead. AT&T was glad to get rid of all that non-revenue
> dead weight traffic. So send thanks to Larry King for his abuse of the
> network which led AT&T to install the 'feature' you do not like.   PAT]

This makes even less sense on the part of AT&T.  They are willing to
anger someone with an audience the size of Larry King's, and suffer
his public endorsement of their competitor for a miniscule amount of
potential lost revenue from a couple of dozen callers a day listening
to ringback tone?  Somehow, "all that" non-revenue traffic seems
bearable in the face of free advertising for Sprint on the Larry King
show.  I'll bet Sprint is delighted to take such "abuse".


Jay Hennigan    jay@rain.org


[TELECOM Digest Editor's Note: It was never a question of how much
or how little network resource was being used. Obviously it was only
a drop in the bucket regards the overall network, although it may
concievably choked things up a little in the local center where King's
calls terminated. The point was that King was unwilling to pay part
of the cost involved in his business communications, yet he wanted his
'customers' to maintain their goodwill, so he pawned off what should 
have been his expense (if he wanted his callers to get by as inexpensively
as possible) onto AT&T. It certainly was not their problem either. I
think AT&T simply looked at him as sort of a petty leecher, ripping off
a little bit at no cost to enhance his position.   PAT]

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

Date: Mon, 02 May 1994 01:53:07 -0400
From: Jonathan <jdl@wam.umd.edu>
Subject: Re: Unwelcome AT&T "Feature"


I disagree with the conventional wisdom on the unwelcome AT&T
"feature."  I believe that it is a VERY good idea to disconnect
callers after the called party number does not answer or gives a busy
signal for several minutes.  This condition may occur when the caller
leaves the phone off hook accidentally and also may occur if the
caller leaves the phone off-hook for the purpose of refusing incoming
calls.  Disconnecting the call frees up network resources and prevents
large amounts of toll charges from accruing in a system which does not
accept answer supervision.

However, if the call is placed as 0+ then there should be a way for
the operator to override the feature!

By the way, several times (in the past) I called collect (410) 954-xxxx 
and got a recording saying that all representatives are busy.  After
about 2.5 minutes of waiting I got the recording, your party is not
answering.  we're sorry, but your call will now be disconnected.  This
was very annoying, and the AT&T operator could not override the
recording.  (This was a COLLECT call, as I remember.)  

As I see it, the number ought to have turned on supervision as soon as
the all-attendants-busy recording came on, and the number should have
given a busy signal instead of cutting off if no representative had
picked up in 2.5 minutes.  Actually, with that particular number, I
think that what should happen is that it should say, "We're sorry;
your call cannot be completed at this time unless it is urgent.  If
you have an urgent call, then please remain on line for the next
repair representative; otherwise, please hang up now" if the wait is
longer than 4 minutes.  Supervision should begin about 10 seconds
after the "please hang up now."  The number should never make people
wait and then cut them off after they wait.

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

End of TELECOM Digest V14 #194
******************************


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