🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: sci.electronics
Article #16313

Re: caller id block

#16313
From: Dan Borkowski
Date: Fri, 22 Jan 1993 20:10
59 lines
3839 bytes
In article <1350.442.uupcb@ozonehole.com>, gerald.belton@ozonehole.com
(Gerald Belton) wrote:
> 
> Here at Tulane we have a PBX system where each phone has its own number;
> you dial directly to the phone on my desk.  A friend of mine has caller
> ID, and the number that shows on his caller ID box is NOT the number you
> would have to call to reach me.  In fact, it isn't the same number every
> time I call.   He has tried calling the number that shows up on his
> caller ID box, and it just rings with no answer.

The Caller ID service does not adequately address the PBX cases.  The
concept of a PBX is basically to provide phone service to a (could be
large) number of extension phones with a relatively few number of actual
trunks (phone lines) to the public switched telephone network (PSTN),
thereby saving $$$ on trunk connection charges.  As an example, you could
have one hundred extensions but only ten trunks to the PSTN.  This means
that all one hundred phones could be in use simultaneously (if the PBX
power supplies can handle that), but only ten of those could be connected
to a party that is not on the PBX (i.e., in the outside world); the
remainder of the extensions would be limited to talking with other
extensions.

When someone from the outside world dials the telephone number of one of
the extensions, the PSTN routes the call to the telephone company's central
office (CO) which is connected to the PBX.  That CO then grabs one of the
(available) connecting trunks and pulses the dialed extension number; the
PBX recognizes the extension number and routes the call to the correct
extension.  This process is called DID -- Direct Inward Dialing.

When someone on an extension phone calls someone in the outside world, the
PBX grabs one of those DID trunks and outpulses the dialed number to the
CO.  The CO, in turn, outpulses the dialed number and includes the ANI
(Automatic Number Identification -- the Caller ID).  However, this ANI
corresponds with the DID trunk from the PBX on which the call originated,
NOT the actual PBX extension.  The called person's caller ID box will
display the number of the DID trunk between the PBX and the CO.  If that
person tried to call that number, the CO wouldn't have any extension number
to put onto the DID trunk, and the PBX wouldn't know where to route the
call.  One would expect some sort of error message in this case, but those
error messages are generated by the telephone company, and the telco is
routing the call properly here.  The PBX just isn't reacting kindly and is
just dumping the call into lala land, allowing the caller to hear ringback
forever.  I guess it would be nice if the PBX could spit out a message, but
that may be something too complex for the PBX to handle.  Besides, that
would mean that the caller's call would be completed, and they would have
to pay to listen to the message.

The problem with the standard is that the originating CO is responsible for
placing the ANI into the signalling data for the call.  There is no
provision for the ANI to be shipped to the originating CO by the PBX (or
any other CPE) for inclusion with the call.  (If that provision did exist,
it would allow anyone to modify their ANI and give a false caller ID.)


Dan Borkowski
GTE Laboratories Incorporated
dborkowski@gte.com
-------------------
This opinion is all mine...
Technical Details
Message-ID: <dborkowski-220193140904@dborkowski.gte.com>
Path: arc1-ca.pugleaf.net!sparky!uunet!news.centerline.com!noc.near.net!ceylon!dborkowski.gte.com!user
References: <1350.442.uupcb@ozonehole.com>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!news.centerline.com!noc.near.net!ceylon!dborkowski.gte.com!user
From: dborkowski@gte.com (Dan Borkowski)
Newsgroups: sci.electronics
Subject: Re: caller id block
Message-ID: <dborkowski-220193140904@dborkowski.gte.com>
Date: 22 Jan 93 20:10:28 GMT
References: <1350.442.uupcb@ozonehole.com>
Sender: news@ceylon.gte.com
Followup-To: sci.electronics
Organization: GTE Laboratories
Lines: 59