|
|
Message Digest
Volume 28 : Issue 168 : "text" Format
Messages in this Issue:
Re: Re:
Re: 5XB arcana
Re: 5XB arcana
Re: Pulse dialing overhead, was: ANI vs. Caller ID
Re: 4-/10-party lines
Re: 4-/10-party lines
Re: Touch Tone Charges - Bell Canada Still Charges Extra $2.80 a month
====== 27 years of TELECOM Digest -- Founded August 21, 1981 ======
Telecom and VOIP (Voice over Internet Protocol) Digest for the
Internet. All contents here are copyrighted by Patrick Townson and
the individual writers/correspondents. Articles may be used in other
journals or newsgroups, provided the writer's name and the Digest are
included in the fair use quote. By using -any name or email address-
included herein for -any- reason other than responding to an article
herein, you agree to pay a hundred dollars to the recipients of the
email.
===========================
Addresses herein are not to be added to any mailing list, nor to be
sold or given away without explicit written consent. Chain letters,
viruses, porn, spam, and miscellaneous junk are definitely unwelcome.
We must fight spam for the same reason we fight crime: not because we
are naive enough to believe that we will ever stamp it out, but because
we do not want the kind of world that results when no one stands
against crime. Geoffrey Welsh
===========================
See the bottom of this issue for subscription and archive details
and the name of our lawyer, and other stuff of interest.
----------------------------------------------------------------------
Date: Sat, 20 Jun 2009 05:38:24 -0700
From: "Fred Atkinson" <fatkinson@mishmash.com>
To: redacted@invalid.telecom.csail.mit.edu
Subject: Re: Re:
Message-ID: <008a01c9f1a4$0131eef0$c800000a@mishmash>
Folks,
It just seems to me that we have too many replies and not enough in the
way of new topics. That is clearly evidenced by the number of 'Re: *****' in
the Subject lines.
Truthfully, I rarely read anything headed be 'Re: ' any more because
usually it is just comments that beat dead horse to death.
We've got a lot of people in the industry that could provide more
information that is new and fresh [and enlighteningly useful]. They should
have somethign interesting from time to time.
Regards,
Fred
------------------------------
Date: Sat, 20 Jun 2009 12:10:36 -0500
From: Jim Haynes <jhhaynes@earthlink.net>
To: redacted@invalid.telecom.csail.mit.edu
Subject: Re: 5XB arcana
Message-ID: <dtSdnT6KMJWRhaDXnZ2dnUVZ_vydnZ2d@earthlink.com>
On 2009-06-19, hancock4@bbs.cpcn.com <hancock4@bbs.cpcn.com> wrote:
>
> In the IBM history, there is mention of "wire spring relays" as being
> a big improvement, and _possibly_ invented by IBM. I'm not sure what
> they are and why they are superior. But apparently they allow
> equipment to be smaller and work faster.
The IBM and Western Electric wire spring relays were quite different
from each other. Indeed the whole logic of relays was different
between the two companies. IBM didn't have a relay contact open or
close while carrying current - they had big contacts like automotive
distributor breaker points that were activated by cams on shafts and
did all the circuit making and breaking. The relays just steered the
signals. What makes this possible is that in punched card machines
everything is under control of the card position as it moves through
the machine, hence is related to shaft rotation. In the telephone biz
everything was asynchronous. Because they didn't make and break
currents the relay contacts could be quite delicate in IBM equipment.
The IBM relay is a beautiful thing to behold. They were made in
widths of 4, 6 and 12 contacts. The only contact arrangement was
SPDT, with the wire springs forming the moving contacts. The fixed
contacts are molded in to the insulator, also serving as connector
pins to make the relay pluggable. The wire spring moving contacts
could be quickly pulled out and replaced. There were various coil
arrangements, and also a latching model with separate coils for
operate and release. Very typical was a low-resistance coil to make
the relay operate quickly and then a higher-resistance coil used to
hold it operated. The wiring side of the relay sockets used tapered
pin connections rather than soldering. The only soldered connections
on the relay itself are the winding connections to the base pins.
------------------------------
Date: Sat, 20 Jun 2009 20:29:59 EDT
From: Wesrock@aol.com
To: redacted@invalid.telecom.csail.mit.edu
Subject: Re: 5XB arcana
Message-ID: <c87.5208e031.376ed907@aol.com>
In a message dated 6/20/2009 2:10:35 AM Central Daylight Time,
xanadu.bbs@example.invalid writes:
> I visited the CEntral CO in Topeka, Kansas around 1970. That was a
> huge Stroger SXS office, with the auxiliary line finders in wooden
> cabinets with glass windows. I forget their actual name, but they
> appeared to oscillate back and forth, left to right, with contacts
> somehow stopping and held to terminals when a subscriber went ROH.
Are you sure that those weren't line switches instead of line finders?
had some of those in in the office named "North," later "JAckson" in
Oklahoma City, added to many times with W.E. SxS switches to
accomodate growth. The line switches were part of the oroginal
Strowger (A.E.?) switches installed when the office was built in 1920.
They continued in service for the original A.E. part until the entire
office was cutover to ESS in a new building built next to the original
in the 1970s or 1980s, and renamed again, this time to "University."
Wes Leatherock
wesrock@aol.com
wleathus@yahoo.com
------------------------------
Date: Sat, 20 Jun 2009 13:54:25 -0500
From: bonomi@host122.r-bonomi.com (Robert Bonomi)
To: redacted@invalid.telecom.csail.mit.edu
Subject: Re: Pulse dialing overhead, was: ANI vs. Caller ID
Message-ID: <vvCdnRQco-_8raDXnZ2dnUVZ_vqdnZ2d@posted.nuvoxcommunications>
In article <1d4c87b9-bb0f-44b9-9382-8f222d1de402@z7g2000vbh.googlegroups.com>,
<hancock4@bbs.cpcn.com> wrote:
>On Jun 19, 4:08 pm, bon...@host122.r-bonomi.com (Robert Bonomi) wrote:
>
>> Lets run some numbers for a big switch. 10,000 lines per prefix,
>> the switch handles 5 prefixes, (50,000) lines. To reliably detect
>> 20PPS dialing requires a minimum of 80 samples/line/second, [or]
>> 4,000,000 samples/second. scan logic resembles:
>
>FALSE TO FACT: Here's why:
>
>1) Please explain how switchhook flashing is detected, and determined
>to be a flash, not a new call. By your logic merely scanning for
>flashing would overload the switch. Obviously it doesn't.
I always maintained switchook flash is detected by -hardware-, just like the
on-hook/off-hook transitions. It's a simple, *cheap* differentiator, doesn't
require 'real-time' reactivity. *ALL* it does is detect continuity changes
that occur on the line, with a simple hysteresis function to suppress 'very
short duration' false positives. By simply adding about 3 instructions to
the interrupt service routine that responds to a DC-continuity change, one
can make a decision as to whether the circuit was 'on hook' "long enough" to
constitute a 'hang up', or whether it was only a 'flash'.
The same hardware _could_ be used to detect dial-pulses, *but* on a
DTMF-enabled line, where a 'hard real-time' task is already slotted to
sampling the audio channel it is much more efficient to add the handful
of instructions to -that- task, to sample the continuity state *without*
the overhead of the interrupt. (This software-scanning over hardware-
interrupt benefit exists _only_ because the scanning is _already_ being
done for DTMF recognition. _One_ scan with two functions is generally more
efficient than one scan plus one interrupt-service, even when the 2nd function
is infrequently needed.)
>2) Not all lines of a switch can dial at the same time, only a small
>proportion.
*PROVING* that it is not done by software scanning all the lines -- like you
have claimed as being done for off-hook detection.
Thank you for making the point, for me.
>3) Testing for dial pulses would be done only for subscribers actually
>dialing a call.
That runs counter to your claim that it is done by *same* routine that
detects on-/off-hook -- which,it should be obvious -- must be scanning
continuously.
It's worth noting that I have asserted from word one that pulse handling
would be done _only_ during call set-up.
You've previously claimed that it is part of the routine that
continuously scans all lines for on-/off-hook detection. [Have you]
changed your mind on that?
>4) Some sort of scanning is still required for Touch Tone entry to
>collect the digits.
To be technically accurate, software-based DTMF detection requires
frequent _sampling_ of the particular line, during call set-up. *Or* a
hardware-based digit decoder to be switched onto the line for the
set-up interval.
>5) If scanning (polling) is done, it is done by a separate signal
>processor, not the CPU.
It still takes 200+ million instructions/second of secondary processor
capacity, be it one 200+ million instruction/sec processor, or 20 10+
million instruction/second one. However you do it, that much
processing power costs non-trivial money.
>6) As the other poster described, probably scanning isn't done, but
>processing handled by interrupts when either a switchhook or dial
>pulse is transmitted.
That is _exactly_ how I have claimed switch-hook detection was done,
and that you've been insisting is wrong.
>7) Your description describes what a switch does _not_ do.
The fact remains that that is what is _necessary_ to do things the way
you claim they are done.
>I don't understand what point you're trying to make with all of this.
>As mentioned before, so few people make dial pulse calls the issue is
>moot.
The point *IS* that 'few people use pulse dialing', [and] that it
_does_ require a "disproportionate" amount of switch resources to
handle pulse vs tone dialing, [and] that those resources _do_ cost
money. Distributing that increased cost burden over the *small*
number of people who 'may' use it *DOES* justify a 'surcharge' for
that functionality.
>> If one assumes that off-hook is detected by hardware, which
>> generates an interrupt, and that the pulse scanning logic is
>> activated only then, and stays active for 20 seconds , with a
>> switch-wide average of 20 outgoing calls/day/line, the scanner is
>> active for a total of 400 seconds/line, instead of 86,400.
>
>If interrupts are used, as we believe they are, there is no need to
>scan at all.
"Surprise, surprise, surprise!!" <grin>
That's exactly what I've been asserting the entire time.
> ... Generate an interrupt for each DC signal event. This _must_ be
> done now to handle flashing and supervision.
That's exactly how I've been claiming on-/off-hook detection is done.
For that detection it is desirable to have hysteresis in the detector
so that it does -not- false-positive on short-duration events. (It's
easier/quicker/cheaper/simpler to do that in hardware than filtering
those spurious events in software.)
When one gets out of the call set-up phase, it is trivial to 'flip a
bit' on a configuration register, and change the hysteresis constant
to respond to flash-type signals, while still ignoring (in hardware)
shorter-duration events.
>> Assume that the interrupt service overhead is 40 instructions
>> (_way_ high), and you've reduced the CPU 'overhead' load from 20%
>> of capacity to 0.20% of capacity.
>
>Interrupts need not be handled by the CPU. Full sized ESS had signal
>processors independent of the CPU to handle that. IBM mainframes have
>channel processors independent of the CPU to handle Input/output
>devices, and they handle I/O interrupts and intefaces. (Low end ESS
>and mainframes intended for light duty had the CPU handle that stuff
>to save money.)
I'm not going to debate 'who does what' within the 'committee' of
processing elements inside a large computer system. You've still got
to have 200+ million instructions/second of capacity at whatever level
of processor is doing the line scanning, *if* comprehensive
line-scanning is, in fact, being done per your claims. Plus, there
are additional 'overhead' instructions at that level for (a) the
interrupt service overhead, and (b) communicating the data to the
'higher level' processor.
Note: I was *deliberately* over-estimating the overhead of doing
things via interrupts, to make a point. WITH _overly-expensive_
interrupt-driven logic, it is still one thousand times 'cheaper' in
CPU requirements to use interrupts over pure scanning. Using
'realistic' costs for interrupt- driven overhead, the advantage only
gets _bigger_.
>***** Moderator's Note *****
>
>The ILEC's didn't dump party lines: they simply withdrew the tariffs,
>and then offered the same service as "Ringmate". This is a win/win: it
>uses the equipment that would otherwise be idle, and gives parents a
>chance to have a separate number for the kids at minimal cost.
>
>I doubt a switch owner would remove equipment once installed, including
>party line capabilities, but especially dial pulse: after all, there's
>no telling when someone with a 554 set on the wall of their bomb
>shelter will lock themselves in ...
*OR* the TT generator in the 'modern' set dies, and you can't
hook-flash 10 or more times to reach the operator in a life-and-death
situation. <evil grin>
------------------------------
Date: Sat, 20 Jun 2009 14:11:51 -0500
From: bonomi@host122.r-bonomi.com (Robert Bonomi)
To: redacted@invalid.telecom.csail.mit.edu
Subject: Re: 4-/10-party lines
Message-ID: <s7-dnSq0V_fqqaDXnZ2dnUVZ_i2dnZ2d@posted.nuvoxcommunications>
In article <db70b$4a3c6526$4aded8bf$9907@EVERESTKC.NET>,
>
>***** Moderator's Note *****
>
>
>Even now, the Ringmate offering (which _is_ two party lines in one
>home) comes in handy to tell "friends" apart from "everyone else",
>so "party" lines will be with us for a while yet.
Sometimes there are alternative solutions... Just out of college, I
would befuddle my roommate when the phone would ring, and I'd just look
up, and say "it's for you". And it was. Or I'd just answer it myself
when it was for me.
After a few weeks of this, the phone rang one evening, and I didn't answer,
nor tell him it was for him. He looks at me and challenges "who's that call?"
I shrugged, and said "wrong number." He answered, and it _was_.
About all the explanation I could give at the time was "I could tell by the
sound of the ring." <grin>
What was really going on was some below-the-conscious-level pattern
recognition. Both my friends, and his, tended to call at somewhat
predicatable times of day. Our families were in different time-zones,
so an "after-dinner" call, from them, for example, occurred at different
times, depending on who it was for.
------------------------------
Date: Sat, 20 Jun 2009 18:58:24 -0500
From: "John F. Morse" <xanadu@example.invalid>
To: redacted@invalid.telecom.csail.mit.edu
Subject: Re: 4-/10-party lines
Message-ID: <7ec72$4a3d77a2$4aded8bf$31265@EVERESTKC.NET>
Robert Bonomi wrote:
> In article <db70b$4a3c6526$4aded8bf$9907@EVERESTKC.NET>,
>
>> ***** Moderator's Note *****
>>
>>
>> Even now, the Ringmate offering (which _is_ two party lines in one
>> home) comes in handy to tell "friends" apart from "everyone else",
>> so "party" lines will be with us for a while yet.
>>
>
>
> Sometimes there are alternative solutions... Just out of college, I
> would befuddle my roommate when the phone would ring, and I'd just look
> up, and say "it's for you". And it was. Or I'd just answer it myself
> when it was for me.
>
> After a few weeks of this, the phone rang one evening, and I didn't answer,
> nor tell him it was for him. He looks at me and challenges "who's that call?"
> I shrugged, and said "wrong number." He answered, and it _was_.
>
> About all the explanation I could give at the time was "I could tell by the
> sound of the ring." <grin>
>
> What was really going on was some below-the-conscious-level pattern
> recognition. Both my friends, and his, tended to call at somewhat
> predicatable times of day. Our families were in different time-zones,
> so an "after-dinner" call, from them, for example, occurred at different
> times, depending on who it was for.
Robert, I too used to work the old below-the-conscious-level control.
But mine was for outgoing (originating) calls. Nobody ever wanted to
call me. :-(
I could simply think of someone who I wished to call, and the dial would
start turning.
The major problem was the fingerstop was absolutely no help, so I often
ran the selectors to tell-tale! ;-)
--
John
***** Moderator's Note *****
Those of us who knew the Hayes command set were able to perform
similar feats of telekinesis: I could start a script in my terminal
program, walk out to where my wife was sitting, and pick up the phone
just in time to "voice activate" the call. It was a mixed blessing:
she'd always get mad when it didn't work for her, and when I finally
fessed up, she didn't talk to me for three days!
------------------------------
Date: Sat, 20 Jun 2009 23:52:54 GMT
From: Mike Spencer <mds@bogus.nodomain.nowhere>
To: redacted@invalid.telecom.csail.mit.edu
Subject: Re: Touch Tone Charges - Bell Canada Still Charges Extra $2.80 a month
Message-ID: <873a9ulbjp.fsf@bogus.nodomain.nowhere>
jwillis <jwillis.removethis@drlogick.com> wrote:
> Fast forward to 2009...
>
> Bell has grandfathered all rotary dial lines - if you dont move you
> dont have to pay the $2.80 a month for Touch-Tone, they put a filter
> on the line so that Touch-Tone will not dial out. If you move then
> Bell will start charging the $2.80 extra a month.
In the late 80s we (in Nova Scotia, with then Maritime Tel & Tel) were
upgraded from a rural party line to a single line. We discovered tha
touch tone was enabled. We had rotary phones but our computers could
use tone. After a few weeks, they somehow disabled it and we were
back to pulse dial only.
The coda was that about 6 years ago, we had 60hz hum on the line and
the tech workers were on strike. After three different fruitless
visits from teams of various marketing, accounting and management
guys, one of them drove off in the truck to the electronics cabinet a
couple of miles away and (so he said) stuck in a new circuit board.
The hum went away and we were converted to tone dial. Since I'd been
collecting up 2500 sets for years, we just plugged them in as were
good to go with no arguments about whether or not we should pay for
"premium" service.
The downside was that we had been paying a buck or so a month to rent
the dial phones for decades. Ho hum. :-)
--
Mike Spencer Nova Scotia, Canada
------------------------------
TELECOM Digest is an electronic journal devoted mostly to telecom-
munications topics. It is circulated anywhere there is email, in
addition to Usenet, where it appears as the moderated newsgroup
'comp.dcom.telecom'.
TELECOM Digest is a not-for-profit, mostly non-commercial educational
service offered to the Internet by Patrick Townson. All the contents
of the Digest are compilation-copyrighted. You may reprint articles in
some other media on an occasional basis, but please attribute my work
and that of the original author.
The Telecom Digest is currently being moderated by Bill Horne while
Pat Townson recovers from a stroke.
Contact information: Bill Horne
Telecom Digest
43 Deerfield Road
Sharon MA 02067-2301
781-784-7287
bill at horne dot net
Subscribe: telecom-request@telecom-digest.org?body=subscribe telecom
Unsubscribe: telecom-request@telecom-digest.org?body=unsubscribe telecom
This Digest is the oldest continuing e-journal about telecomm-
unications on the Internet, having been founded in August, 1981 and
published continuously since then. Our archives are available for
your review/research. We believe we are the oldest e-zine/mailing list
on the internet in any category!
URL information: http://telecom-digest.org
Copyright (C) 2008 TELECOM Digest. All rights reserved.
Our attorney is Bill Levant, of Blue Bell, PA.
************************
---------------------------------------------------------------
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 fifty dollars
per year per reader is considered appropriate. See our address above.
Please make at least a single donation to cover the cost of processing
your name to the mailing list.
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.
End of The Telecom digest (7 messages)
******************************
|
or 