Visit our newest sister site!
Hundreds of free aircraft flight manuals
Civilian • Historical • Military • Declassified • FREE!


TUCoPS :: Phreaking Technical System Info :: testline.dox

Tutorial on test trunks




From: Raymond J. Rueb
How Toll Busy Line and Emergency Interrupt Work


After reading the previous discussions, I think there is some
confusion about what the operator is capable of during BLV and EI
situations. So,

     "How Toll Busy Line Verify (BLV) and Emergency Interrupt (EI) Work"

I worked on OSPS BLV & EI for AT&T, and I became familiar with how
TSPS works also. For TOPS info, ask someone else (though this
information should be close).

The best way to understand BLV and EI is to run through a customer to
operator to termination scenario.

1) After repeatedly receiving a busy signal from their intended
forward number, a customer calls the operator and asks if the operator
can help.

2) The operator enters "VERIFY mode". On TSPS this is done by
accessing a separate call loop and performing the VERIFY on that loop.
On OSPS the operator has a separate VERIFY key to press which causes
the switch to perform the following checks:

  a) Is there a valid forward number?
  b) Is the forward number within this operator's VERIFY network? If
     not, the operator must go inward to the local operator who can
     then perform the VERIFY. More about VERIFY networks later.
  c) Is the forward number verifiable? ie: is it on the list of numbers
     of which the operator is not allowed to perform BLV and EI. I never
     understood this idea, maybe the CIA might rest easier, but it really
     is a security redundancy.

3) If this operator can perform the VERIFY, then the operator presses
send.

  a) The call begins to route over the VERIFY network.
  b) The back party is automatically split from the connection (for
     security reasons, OSPS only; in TSPS the operator is performing the
     VERIFY on a separate loop and there is no back party on that loop)
  c) The operator's talking path is disabled.
  d) A voice scrambler circuit kicks in (in TSPS this is a physical
     circuit attached to the trunk, in OSPS this is firmware in the
     operator's VDT). The scrambler allows the operator to tell IF
     conversation is taking place, but not WHAT is being said.
     It kinda sounds like ducks talking.

4) The call arrives at the local Central Office (CO) on an incoming
BLV trunk.  This is where my knowledge is a little weak. If the number
to be verified is a line loaded on that switch, then we're home free.
The switch automatically causes a test trunk to bridge the port
associated with the number being called and the operator is now
connected with all forward parties associated with the call. If,
however, the line is on a PBX connected to the CO, the connection MAY
be verifiable. I believe all true PBX's must have incoming VERIFY
trunks and be capable of performing BLV bridging. I know that some
PBX's can do this (a 5ESS Switch (tm) can be a PBX), but I don't know
whether ALL PBX's can do this. It works on centrex.

5) The operator listens to the scrambled connection to determine if
the line is in-service or not. This method of determination has the
following drawbacks:

   a) If there is a long lull in the conversation when the operator
      performs the VERIFY, the operator might assume that the number is
      out of service.
   b) Most operators don't seem to be able to recognize data connections
      through the scrambler (what's that funny noise???)
   c) A pre-howler announcement, "please hang-up the phone" sounds like
      conversation. There's actually a lot of debate as to what constitutes
      in-service; if the telco's product is working, but the person has
      recently left the phone off-hook, is it in-service?

6) The operator splits the forward connection, unsplits the back party
(TSPS operators change loops) and informs the customer of the status.

7) The customer requests an EI.

8) The OSPS operator presses the EI key.

   a) The back party is split.
   b) A two second long 440Hz tone is applied to the forward connection.
   c) The scrambler is deactivated.
   d) The operator's voice path with the forward connection is restored.
   e) Every 10 seconds, a 0.5 second tone is repeated to serve as a
      reminder to the forward parties that their conversation is no longer
      private. This tone continues until the operator breaks the EI bridge.

9) The operator can now talk with the forward party and request that
they hang-up so that the back party can call them.

10) The operator relays the response to the back party.

At this point the operator will charge the customer for the VERIFY and EI.

If they have been taught well, the operator will ask if the back party
wants the operator to connect them with their intended forward party.
This will result in additional charges for an operator assisted call.

NOTES about BLV and EI service:

1) BLV and EI are separately tariffed services, but are always flat
rate. Some states, like Michigan, don't allow charging for BLV but do
allow EI charges.

2) During VERIFY and EI, the back party and forward party are NEVER in
contact.

3) Calls CANNOT be completed across the VERIFY network.

4) The VERIFY network USUALLY crosses LATA boundaries.

5) The VERIFY network is often BOC owned, and often only the BOCs are
allowed access to them. This means that BOCs frequently are in the
position of providing INTER-LATA BLV and EI services. Since BOCs are
forbidden from providing inter-lata services like COLLECT and CARD#,
why is inter-lata BLV allowed?

NOTES about the VERIFY network and security:

1) The VERIFY network is separate from the toll network.

2) Routing on the VERIFY network cannot occur from a customer's phone.
If you're accidently routed to a VERIFY trunk, your signaling will be
wrong.

3) Much emphasis has been placed on operators being able to break into
private phone conversations as a breach of privacy. Given the way BLV
and EI perform (with the scrambler and tones) I don't feel that this
is an issue.

                        HOWEVER....

4) Craft test sets have special software to prevent routing on trunks
MARKED as VERIFY trunks, but there is NOTHING to prevent a craft
person from modifying how a trunk is marked, and then routing (of
course it is still special routing signalling that must be used, but
them craft seem to know about it).  I was appalled to find out that
this is common practice when testing the BLV trunks. What this means
is that a skilled, but unscrupulous, craftsperson has the
unsupervised, unmonitored, unscrambled ability to listen in on ANY
active phone conversation anywhere their VERIFY network reaches. Guess
you gotta trust them.


TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2014 AOH