Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!mailrus!accuvax.nwu.edu!nucsrl!telecom-request
From: forrette@sim.berkeley.edu (Steve Forrette)
Newsgroups: comp.dcom.telecom
Subject: Re: More ANI Fun!
Message-ID: <10460@accuvax.nwu.edu>
Date: 4 Aug 90 00:00:00 GMT
Sender: news@accuvax.nwu.edu
Organization: University of California, Berkeley
Lines: 26
Approved: Telecom@eecs.nwu.edu
X-Submissions-To: telecom@eecs.nwu.edu
X-Administrivia-To: telecom-request@eecs.nwu.edu
X-Telecom-Digest: Volume 10, Issue 542, Message 11 of 11


In article <10431@accuvax.nwu.edu> Arnette Baker writes:

>I was definitely NOT calling over MCI,
>since I work for AT&T and called from my desk. |^)

But you WERE!  As others have pointed out, 800-666 is owned by MCI.
Whenever any call is placed to 800-666, your CO directs the call to
MCI's POP and they handle the call from there.  Your default equal
access carrier doesn't even come into play.

>This problem may depend on the type of CO switch, but to my 
>knowledge there is no protocol yet defined to pass SS7 type 
>information from a PBX to a CO.

One of my friend's dad works for US West, and we were talking about
SS7 one day.  He mentioned that Hewlett Packard in Corvallis, OR is
currently testing SS7 services delivered to the customer.  Apparently,
there is some sort of protocol defined.  He indicated that in the near
future, high-end PBX's will be able to have a 56kbps SS7 connection to
the CO, in addition of course to the analog trunks, or that one of the
channels in a T1 could be devoted to this purpose.  This would allow
the PBX to directly access and control the SS7 features for the
customer's lines.  Presumably, all call setup could be done over the
SS7, instead of the in-band DTMF or MF or whatever the analog trunks
are using now.  Interesting.