telecom@ucbvax.ARPA (04/07/85)
From: Jon Solomon (the Moderator) <Telecom-Request@BBNCCA>
TELECOM Digest Sat, 6 Apr 85 19:38:33 EST Volume 4 : Issue 177
Today's Topics:
alternatives to modems (query)
Re: alternatives to modems (query)
ATT&T glossy advertising -- proto
Delayed Call Forwarding weirdness
----------------------------------------------------------------------
Date: Apr 1985 4 11:12-EST
From: David.Anderson@CMU-CS-K.ARPA
To: videotech@sri-csl, telecom@bbncca, info-hams@brl
Subject: alternatives to modems (query)
I'm looking for information on higher bandwidth alternatives to modems
for communications from our department to off-campus users. The
technologies that I'm considering include using an otherwise unused
cable channel, packet radio, and anything else you can suggest. I'm
looking for pointers to existing systems in other cities, technical
articles describing these technologies, and vendors of off-the-shelf
equipment. Please respond by mail, and I'll post a summary later.
------------------------------
Date: Fri, 5 Apr 85 10:09 PST
From: Thomka.es@Xerox.ARPA
Subject: Re: alternatives to modems (query)
To: David.Anderson@CMU-CS-K.ARPA
If you have the equipment to transmit a closed cable television channel
you may look into having a full teletext channel (no picture, using
almost the entire 525 lines for teletext code).
I'm not suggesting that you send out a picture, just that you use the
technology to send data to a decoder on the other end of the cable.
With a 5.7 Mbit/sec. rate, which US teletext uses, you could get super
fast data transmision, even if you included a lot of error checking and
correction.
See Radio and Electronics magazine Nov81, Dec81 and Feb82 for a 3 part
article on what teletext is and is capable of.
Chuck
------------------------------
Date: Fri, 5 Apr 85 13:29:50 PST
From: "Theodore N. Vail" <vail@UCLA-LOCUS.ARPA>
To: telecom@bbncca.arpa
Subject: ATT&T glossy advertising -- proto
I just received a fancy advertising brochure from AT&T Bell
Laboratories. It contained a lot of spiff about high-visibility
projects at Bell Labs, an editorial about the "ultimate network" (i.e.
AT&T's Network Systems), etc. It is well done and quite similar to what
I receive from many other large corporations.
The unique difference is that it came with a letter inviting me to
subscribe to future issues for $15.00 per year!
With this kind of merchandising effort, how can AT&T's competition fail to
succeed?
ted
------------------------------
Date: Fri 5 Apr 85 16:41:22-PST
From: Ole Jorgen Jacobsen <OLE@SRI-NIC.ARPA>
Subject: Delayed Call Forwarding weirdness
To: TELECOM@BBNCCA.ARPA
I want to tell you about a an interesting hassle I am having with
Pacific Bell, and maybe someone can make a few comments based on your
knowledge of how an ESS works, or perhaps point me to some wizard that
can verify this behaviour.
A couple of weeks ago I had "Delayed Call Forwarding" (DCF)
installed on my 325-9427 number. This feature (also commonly known as
forward-on- no-answer) allows the incoming call to be routed to a
secretary, answering service or whatever. The restriction is that the
destination number is FIXED, it is programmed in at the time of
installation, and to have it changed you pay another $6 and presumably
wait a couple of days. Well, since I have TWO lines, the obvious way
to make this a more flexible service is to have the DCF go to my OTHER
number, 325-9542 which in term would be variably forwarded to the
number of my choice.
This would yield the following (expected) behaviour:
1. You call 325-9427
2. You hear 3 rings
3. On (or about) the 4th ring the call is transferred to
325-9542 which rings ONCE to indicate that it is forwarded
4. Normal forwarding then takes place (the caller hears ringing
while all this is going on) and the destination number is
reached.
BUT, this does not work at all. When the second line is forwarded,
no DCF to that line takes place and the phone will ring forever on the
first -9427 number. I tried to explain to the Pac Bell people that this
was very undesirable and only works this way because both numbers are on
the SAME ESS. In other words, the ESS "knows" that -9542 is forwarded
and this somehow overides DCF. The way they explained this to me is that
there are conceptually TWO tables, one dynamic (for normal call forwarding)
and one fixed for DCF. The fixed "DCF-table" is altered when -9542 is
forwarded and this results in a "no-go" for DCF.
If you instead have DCF going to ANOTHER CO, the first CO has
no "knowlege" of any forwarding tables in the second CO and therefore you
can merily forward your DCF destination number to wherever you like and
things will work as one normally expects.
Now for the punchline: Pac Bell cannot determine whether the above
restriction is a bug or an intended feature and have requested Bell Labs
to investigate, something which apparently takes 6 months or more. Meanwhile,
I am considering biting the dust and having the DCF go to another CO (my
office) and "steer it" from there.
If anyone out there has extensive knowledge of ESSs, I would
appreciate a message or a call, is this a bug or a feature??
<OLE>
-------
------------------------------
End of TELECOM Digest
******************************