Path: utzoo!utgpu!attcan!uunet!husc6!bbn!mit-eddie!killer!vector!dgc
From: dgc@math.ucla.edu (David G. Cantor)
Newsgroups: comp.dcom.telecom
Subject: (none)
Message-ID: <520@vector.UUCP>
Date: 30 Jul 88 04:02:29 GMT
Sender: chip@vector.UUCP
Lines: 37
Approved: telecom-request@vector.uucp (USENET Telecom Moderator)
X-Submissions-To: telecom@xx.lcs.mit.edu (Mailing List Coordinator)
X-Administrivia-To: telecom-request@vector.uucp (USENET Telecom Moderator)
X-TELECOM-Digest: volume 8, issue 118, message 1

In telecom #115, David Lesher statees

	In the past, a number set to forward allowed multiple calls to
	be in progress at once (provided, of course that the recipient
	number had rotary lines to handle them).  This was a great
	advantage to many ports, because a 'fringe' phone could extend
	the local calling area.

	I now hear that our good friends at AT&T have rewritten the
	switch software to exclude this possibility.  Anybody care to
	confirm/deny or otherwise expound?
 ------------------------------------------------------------------------
Yes, I have a foreign exchange (FX) line which I have set to
call-forward to a two-line rotary.  When I began to get unexpected
"busy's" when dialing the FX line, I did some checking.  Careful
experimentation verifies the above statement.  Specifically, if a call
is being forwarded, the system won't forward another (even when the
other line of the rotary is free).  What is surprising is that both the
FX and the two rotary lines are on General Telephone (GTE) exchanges;
both are ESS.

So I am reduced to two calls at a time on my FX:  One out-going and
one in-coming (forwarded) call.

Here is a question of mine:  Given the capabilities of the ESS, why
isn't the FX line provided in software?  At the moment, a special very
long loop (about 15 miles) is run to provide my FX.  Why doesn't the
telco simply use call-forwarding type software (for incoming calls) to
send the call to a special line on a local exchange and thus use their
high-volume, low cost toll lines instead of expensive very long loops.
Outcoming charges can be handled by the computer billing programs.

dgc

David G. Cantor
Internet:  dgc@math.ucla.edu
UUCP:      ...!{randvax, sdcrdcf, ucbvax}!ucla-cs!dgc