From: varney@ihlpl.att.com (Alan L Varney)
Newsgroups: comp.dcom.telecom
Subject: Re: Does SS7 Support Early Busy Signal?
Date: 16 Nov 92 13:10:25 GMT
Organization: AT&T Network Systems, Lisle, IL
X-Submissions-To: telecom@eecs.nwu.edu
X-Administrivia-To: telecom-request@eecs.nwu.edu
X-Telecom-Digest: Volume 12, Issue 854, Message 11 of 12

In article <telecom12.842.12@eecs.nwu.edu> capek@watson.ibm.com
writes:

> While trying to make a credit card call to a persistently busy number
> recently, after typing in the card number for the n-teenth time, I
> wondered if SS7 protocol would allow the calling exchange to "look
> ahead" at the called number and inquire if it is (at that instant)
> busy, before prompting me for the card number.  Of course, I might
> still get a busy if either the line became busy after I keyed in the
> credit card number, or if the response to the query didn't make it
> back to the originating exchange in time. The advantage (to me) would
> be not having to repeatedly pound in the billing.  The advantage
> (small) to the carrier would be not having to do the credit card
> verification, and perhaps getting the line on which I'm calling free a
> bit quicker.  If the call in question were third party bill, or
> collect, the savings could be a lot greater.

   Brief answer: It's possible.  SS7 supports a "primitive" query of
'distant line status'; the response indicates busy/idle and some other
information.

   However, there are problems with this mechanism.

1) Only very recent standards changes support such queries over IC SS7
facilities (that is, between LATAs).  Since your call probably would
reach IC operator facilities on the larger ICs, this isn't a huge
issue, but until such standards are implemented, ICs that use the LECs
for operator services would have a problem.

2) There is currently no standard for "billing" an IC or LEC for the
query, unlike the billing mechanism for queries about LEC calling
cards and 'static' line information (e.g., line does not accept
collect calls).  If the query were billed similarly to the calling
card database, it would likely cost more (in access charges) than the
cost of attempting to complete a call to the line.  It's true that
when real operators are involved, the early query might save the IC
some operator time and reduce costs.  The current implementation at
least slows down the number of uncompleted call attempts you can make :-).

3) Customer confusion about the meaning of "busy" during dialing.
Today, such a tone usually means you mis-dialed the call.  I would bet
there would also be hundreds of "auto-dialing" systems confused by the
tone.  If the response to such confusion is to re-try the call, the IC
has gained nothing.  Such repeated attempts cost the IC a small sum,
but generate no revenue.

(Such auto-dialing systems might include "smart" coin phones, PBXs,
credit-card POS units, etc.  All this "smart" CPE causes lots of
problems whenever the telephone network is changed in very small ways
 -- much of it was developed by trial and error using a few leased
lines for testing, and it does not adapt as easily as humans to
changes.)

  The obvious solution to repeated busy tone is also possible with
SS7.  The 'automatic recall' or 'repeat dialing' CLASS capability
would permit one to request the network to call you when the line is
available.  This should work for most non-PBX and non-coin telephones
when the 'query via IC' standards become widely implemented.

   For PBX and coin lines (most coin stations do not have CLASS), the
solution is to "complete" the call even when the line is busy.  The
more obvious solutions are either voice mail, pagers, call waiting, a
portable DTMF generator containing your credit card number (RISKY?),
or a LEC/IC mechanism that provides for automatic repeated message
delivery.  Only the last two methods require no action on the part of
the called party.


AL Varney - just MY opinion.