Date: Mon, 30 Nov 92 11:26:33 CST
From: firstname.lastname@example.org (Alan L Varney)
Subject: Re: CPC Detection and Purpose
Organization: AT&T Network Systems, Lisle, IL
In article <email@example.com> Irving_Wolfe@happy-man.com
> Okay, since PAT stepped into this with more information, let me also
> expand the question about CPC.
> Aspect 1: What _exactly_ is going on, and how does this differ between
> modern CO switches and the older ones some of us are forced to endure?
> Does the service depend on the switch?
Some switches, because of their design, provide varying intervals
of open circuit (no current) on loop-start lines when a calling party
disconnects (no current at called end) or when the called party
disconnects beyond the "timed-disconnect" interval of 10-12 seconds
(no current at calling end). This interval might vary with intra- vs.
inter-switch calls and might (or might not) appear depending on other
factors. For answering machines, the interruption in current after
calling party disconnect is commonly called CPC.
Note that CPC, if/when it exists, was a side-effect of design, and
not a requirement on the CO switch. After all, CO switches were
designed to work with "smart" people using tones for call progress
information. The more recent use of "smart" CPE on loop-start lines
and the use of DC signals by the CPE was not factored into the switch.
Only the most recent versions of Bellcore's LSSGR have added a
requirement to interrupt line current for about 800 msec. on most
forms of far-end disconnect. This won't magically change the way most
existing COs work.
This is why, in Bellcore's SR-TSV-002275, "BOC Notes on the LEC
Networks - 1990", the following paragraph appears:
The network currently provides no system-standard release
signals on loop-start lines. Even in switching systems
that do provide loop current interruption as part of the
permanent signal treatment, range-extension equipment will
block this signal from reaching the terminal. Therefore,
a terminal for loop-start service SHOULD NOT BE DESIGNED
TO DEPEND ON LOOP CURRENT INTERRUPTS IN PERMANENT SIGNAL
TREATMENT FOR USE AS PRIMARY DISCONNECT SIGNALS.
Keep in mind that SR-2275 documents how the network works today --
you can't depend on CPC. The LSSGR documents how NEW CO equipment
should work -- so that the 800 msec. interruption will become more
> Aspect 2: More advanced phone systems allow one to set a time in
> milliseconds for CPC reaction, without explaining anything about what
> this means or how to decide. I guessed that this was a way of having
> the phone system dump a dead call, since CPC wouldn't carry through to
> an answering machine beneath the (Panasonic 1232) phone system;
> failure to dump a dead call results in the CO line being held active
> at our end and we eventually get either a nobody-there when someone
> answers or else the answering machine gets a message from the local
> "telco" saying "your call could not be completed as dialed".
> What on earth is the time referring to, and can I set it, somehow, to
> eliminate the dead calls from caller hangups that we aren't letting go
> of fast enough? Or is my understanding all wrong?
You might want to discuss this with your Phone Company; they might
be able to arrange your lines for added disconnect processing (longer
opens during some incoming or outgoing calls). This will depend on
your switch and type of line. If you really want a better interface
to a PBX-like switch, also look into the use of "ground-start" lines.
These are designed to eliminate most of the problems with the
CO-to-CPE interface, including provision for current removal when the
CO disconnects from the far-end party. Loop-start lines are marginal
at best for a "smart" CPE interface. Ground-start is better, and ISDN
is better still.
Al Varney - just MY opinion.
From: firstname.lastname@example.org (Al Varney)
Subject: Re: I don't get bumped offline & need to
Date: 22 Jan 1998 15:52:19 GMT
In article <email@example.com>,
Craig Siebels <firstname.lastname@example.org> wrote:
>Boy, we've really gotten off-topic here although this is the sort of
>info that *I* was looking for. I guess that you are right in that
>state-of-the-art means the 'lastest' thing. I just assumed that switches
>were a high tech item, where high-tech means obsolete after five years
But switches are designed (and accounted for) as 40+-year items.
TELCos might replace 5% of their switches every year. I'd love for
it to be a higher rate (since my employer sells them), but you wouldn't
like paying the higher phone bills, right?
Think of switches like office buildings -- there are high-tech
offices buildings, but they don't get torn down every 5 years.
They get remodeled, added to, rewired, etc. Same with switches.
>One question, since you seem to know a heck of a lot about telco
>switches: how difficult would it be for the DMS100 to be programmed to
>break the carrier at the same time one recieves the audible tone
>associated with call waiting?
- As I wrote Craig earlier -
-- I doubt the DMS100 would be difficult to program
to work as you suggest in most cases. However, OSI
(Open Switching Intervals) are something Bellcore says
switch vendors should minimize. OSIs are any break in
loop current after call origination or answer. Some
equipment thinks a drop in loop current means the call
should be dropped (which suits your needs, but not
those of many voice customers, who want to be able to
resume their call or ignore the new call).
Bellcore's LSSGR - GR-505, Section 5.3.1
"The system should minimize the occurrence and duration of open
intervals where battery is not supplied to the line."
Bellcore's LSSGR - GR-506, Section 3.4.7
"It is an objective that an SPCS provide the capability to prevent
LCFO intervals from being applied to an access line during the
service-request, addressing, call-processing and communications
states and during the transition between these call states."
[LCFO is Loop Current Feed Open, another name for OSI]
To my knowledge, no switch vendor has been asked to deliberately
provide OSI during call waiting. Older equipment did so because
connecting in the 3-way call equipment (used even though only two
parties were connected at any one time) required disconnection of
the equipment previously providing battery/ground to those parties.
That older equipment COULD avoid OSI by attaching special assemblies
to lines experiencing problems caused by OSI. Newer switches avoid
this problem (and expense) by avoiding the OSIs in the first place.
Also, many call-waiting customers don't WANT their current
caller to know a new call is coming in, and like call waiting to continue
to work the way it does on digital switches (no OSI).
So any introduction of a deliberate OSI for call waiting would have
to be on a per-line basis, which means customers WANTING IT have to
pay for it. Would it be worth $1/month to have that OSI? $2/month?
If so, and you can convince Bellcore and the folks who pay for new
switch features that they can make a profit here, then make your
case to them.
Or argue to the PUC that OSI is a vital capability for SOME users, and
should be mandated as a free variation of standard call waiting. In this
case, the PUC will likely allow recovery of the cost of the software and
the cost of administering more per-line information by raising slightly the
price of call waiting to all users. As such a user, who doesn't want OSI,
I'd object to that proposal.
(I might add that a similar issue relating to answering machines has
already been fought in the courts and through the FCC. Answering machine
vendors determined that some older switches usually (but not always)
dropped loop current briefly at the called party line when the calling
party hung up. They built equipment that depended on this -- they called
it CPC -- to stop recording messages. Then they found that some newer
switches and some types of connections on older equipment never provided
CPC. After several years of arguing, the FCC added requirements to drop
loop current if the called party didn't hang up after 10-12 seconds after
the calling party hung up. BUT there was no requirement on the TELCos to
spend any money modifying existing equipment to force the drop in loop
current -- since the published loop interface stated there was NO SIGNAL
PROVIDED to the called party on calling-party disconnect. So answering
machines can use the drop in loop current to stop recording, but they can't
DEPEND ON IT working everywhere.)
I'd note that interfaces designed for non-human interactions (ISDN,
for example) provide explicit signals for both new incoming calls and
for disconnected callers. But the standard residential loop interface
was designed for voice calls -- modem vendors have to adapt to what that