Phoenix Rising BBS/phoenixrising.zip/phoenixrising/tele-dig/td14-076.txt

Text File | 1994-02-11 | 30KB | 682 lines

TELECOM Digest     Fri, 11 Feb 94 15:02:00 CST    Volume 14 : Issue 76

Inside This Issue:                          Editor: Patrick A. Townson

    Determining Price/Port (Dan Wing)
    Internet Costs and Software Are Free (A. Padgett Peterson)
    What Telecom Services to Ask For in an Exchange (Jim F. Williams)
    Sources Wanted For Modem Leasing (Scott Chesney)
    Need Voice Mail Reccomendation (Samantha Star Straf)
    International 800 Taboo? (Dan Chang)
    AT&T Merlin vs. NT Meridien Norstar (Rubens Rahim)
    Seeking Information Regarding UPT Standards Draft (Brahmananda Vempati)
    Re: Don't Trust The Phone Company (Curtis R. Nelson)
    Re: Don't Trust The Phone Company (Alan Boritz)
    Re: Don't Trust The Phone Company (Robert Hettmansperger)
    Re: Don't Trust The Phone Company (Tom Olin)
    Re: Don't Trust The Phone Company (Charles Reichley)
    Re: Remote Call Forwarding to Priority Ringing (Al Varney)
    Re: Remote Call Forwarding to Priority Ringing (Steve Cogorno)

TELECOM Digest is an electronic journal devoted mostly but not
exclusively to telecommunications topics. It is circulated anywhere
there is email, in addition to various telecom forums on a variety of
public service systems and networks including Compuserve and GEnie.
Subscriptions are available at no charge to qualified organizations
and individual readers. Write and tell us how you qualify:

                 * [e-mail] *

The Digest is compilation-copyrighted by Patrick Townson Associates of
Skokie, Illinois USA. We provide telecom consultation services and
long distance resale services including calling cards and 800 numbers.
To reach us:  Post Office Box 1570, Chicago, IL 60690 or by phone
at 708-329-0571 and fax at 708-329-0572. Email: [e-mail].

    ** Article submission address only: [e-mail] **

Our archives are located at lcs.mit.edu and are available by using
anonymous ftp. The archives can also be accessed using our email
information service. For a copy of a helpful file explaining how to
use the information service, just ask.

TELECOM Digest is gatewayed to Usenet where it appears as the moderated
newsgroup comp.dcom.telecom. It has no connection with the unmoderated
Usenet newsgroup comp.dcom.telecom.tech whose mailing list "Telecom-Tech
Digest" shares archives resources at lcs.mit.edu for the convenience
of users. Please *DO NOT* cross post articles between the groups. All
opinions expressed herein are deemed to be those of the author. Any
organizations listed are for identification purposes only and messages
should not be considered any official expression by the organization.
----------------------------------------------------------------------

Subject: Determining Price/Port
From: [e-mail] (Dan Wing)
Date: 11Feb 94 04:02:20 MDT
Reply-To: [e-mail]
Organization: Ski Bum Wanna-be, Incorporated


We are attempting to determine per-port prices to charge for Ethernet
connections throughout our strucutures.

Currently, we're planning on something like charging 1/8th of the
price of a 16 port card plus enclosure -- we're looking at 1/8th so we
can pay for the next enclosure plus card when we've filled the current
configuration.

Naturally, this results in high per-port costs, so I'm looking for
creative ways other organizations are determining per-port pricing.

Also, do you charge users a per-month fee (similar to a telephone
connection) to pay for the ongoing maintenance, improvements,
troubleshooting, etc., that are needed for the network?

I'm posting this to some telecommunications newsgroups, knowing that
these issues have already been solved for telephone systems, and the
same thinking could be re-applied to networking -- no need to
re-invent a scheme for providing a service.

[followups directed to comp.dcom.lans.misc please.]


Dan Wing, Systems Administrator, University Hospital, Denver
[e-mail] or [e-mail]

------------------------------

Date: Fri, 11 Feb 94 12:30:18 -0500
From: [e-mail] (A. Padgett Peterson)
Subject: Internet Costs and Software Are Free


A lot of what we have been seeing in this comes under the heading of
PBIs IMNSHO. The Internet is not free, it is paid for by somebody, but
that does not mean that it costs everybody.

Personally, my biggest fear is Junk E-Mail swamping the net. If
anything should be regulated it should be that and with hanging,
drawing, and quartering prescribed for offenders (I know, the ASPCA
would probably object to using horses).

The fact is that whether they realize it or not, modern business/
education cannot exist without the Internet and I can give examples:

Right now some government RFPs (requests for proposal, the way
contractors bid for government contracts) are available on the net.
Used to be that on announcement you had to request the RFP (big
contractors have people in Washington whose sole job is to pick up
documents), it had to travel to you. You had to make copies,
distribute them to approprite people, collect the responses, write it
up, and deliver it back.

Those available via FTP can be retrieved and distributed *now* rather
than in days. Quite an advantage nowadays.

Electronic filing (ask a doctor about the time lags), world wide data
retrieval, submission of papers for comment are all essentail to
modern life. A first-class university *could not exist* without
internet access, businesses are rapidly following suit.

Therefore, in the corporate world, connection (at about $2000/month)
is not a choice, it is a necessity and a sunk cost. For this type of
connection therefore, what is the delta cost of adding another user?
Effectively the same as a university adding another student, negligable
 -- all the costs were already paid in having the access at all.

In making generalities as "a dollar per person", the distinction
between sunk and delta cost is often overlooked but like telephone
service, for the average user, most of the cost is in having a phone
at all, use rarely is a factor.

Similarly, for a corporation/agency/university, the real cost is in
being connected at all, the delta cost for the next user is generally
lost in the noise.

Someone mentioned the cost of equipment as being an important factor.
To me the same rule applies. For a prewired building the delta cost is
limited to the Ethernet card (about $50 nowadays) and extra hub
capability every so often (but that was made in the design stage -- for
thin coax, no hub is necessary and the gateway/router was needed
before the first user was added.

The big nut is still constant -- sunk cost of installation and
reoccuring cost of connection. The number of users really is not
important so long as proper sizing was done initially.

                 ----------------------

Free Software. Just because I do not charge for any of my released
software does not mean that it is free. Rather, I consider it to be
only fair that since I have learned so much from people that I put
something back.

The other motive is educational. I have learned more by saying things/
releasing software and having people (*lots* of people) tell me where
I am wrong than I ever could with my limited resources. Nothing
ventured, nothing gained so I venture a lot 8*).

Besides, ignorance is the tool of dictators and fools. By helping to
stamp out ignorance ("this can be done") and with open discussions, I
like to think that we are supporting democracy.

Finally, I do not like viruses. I believe that I have a better than
average understanding of what they do and I do not like it. Many
people in government and industry realize the same thing but are not
experts so they need expert tools yet often $1.00 is as hard to get as
$1,000,000.00. Therefore, I make my antivirals "freeware" so anyone can
use them without a lot of paperwork and maybe, just maybe, if enough
people use it, we can make viral spread just a bit more difficult.

I always liked the concept that if you help someone, and they help
someone else, eventually it comes full circle. Fortunately I live high
enough in the Maslov hierarchy to afford it.


Warmly,


Padgett


[TELECOM Digest Editor's Note: I've always felt the same way where this
Digest was concerned. It is purely my contribution to the world to help
stamp out ignorance where the operation of telephone networks is concerned.
At least it began that way ... now I think I am a victim of my own success
where the Digest is concerned as the volume of traffic and the size of
the mailing list has increased far beyond what either Jon Solomon or I
expected or considered possible. Part of this of course is due to the
general increase in Internet usage; part perhaps due to my own efforts to
gateway the Digest to so many places. At that I was successful, and now
the mail is pouring in at such a volume that even a cursory examination
of much of it is difficult. And that is not good. I wish I could read
every peice of mail and use every peice of mail I receive, but until the
time comes that I can support myself independent of other outside jobs
 -- if that time ever comes -- and work on the Digest eight or nine hours
per day -- which could easily be done now if resources were available --
then I have to do what I can. I wish I lived high enough in the "Maslow
Hierarchy" to be able to afford it.  PAT]

------------------------------

From: [e-mail] (jim f williams)
Subject: What Telecom Services to Ask For in an Exchange
Organization: The World Public Access UNIX, Brookline, MA
Date: Thu, 10 Feb 1994 21:40:24 GMT


I am connected with the closure and redevelopment of Ft. Devens.  We
want to make it a model community for Hi-tech innovative industries,
perhaps with high-tech residential developments as well (i.e. more
than just POTS services to homes).

9X wants keep an exchange (508-796) in its present location, so we
have some leverage for requesting "state-of-the-art" services.

I thought, at a minimum, that ISDN should be made available (much
earlier than the snail's pace it's being deployed now) in that
exchange for both indistrial and residential service.

Are there other things that we should ask for?  If we built a
community that allowed you good data service at home and at the office
and allowed you to bicycle between them what is needed re telecom (and
CATV)?

Thaks for your input, specifics may be mailed to [e-mail] if
they are not appropriate for posting.


Jim WIlliams

------------------------------

From: [e-mail] (Scott Chesney)
Subject: Sources Wanted For Modem Leasing
Organization: Geophysical Institute, University of Alaska Fairbanks
Date: Fri, 11 Feb 1994 16:50:44 GMT


Does anyone know of a place to lease a pair of 14.4 modems? I will be
needing them yesterday for a couple of months time.  TIA.


Scott                  Network Manager
[e-mail]  [phone]
Geophysical Institute,  University of Alaska Fairbanks


[TELECOM Digest Editor's Note: I am surprised to hear that anyone bothers
to lease modems any longer. That was quite common in the 1970's and early
1980's when they were *so* expensive, but why now?  You can purchase 14.4
units for a couple hundred dollars lots of places; I think even less than
that according to messages here in the past.   PAT]

------------------------------

From: [e-mail] (Samantha Star Straf)
Subject: Need Voice Mail Reccomendation
Date: 11 Feb 1994 10:15:44 -0600
Organization: Another MCSNet Subscriber, Chgo's First Public-Access Internet!


We are thinking about getting a new voice mail system and want
reccomendations.  We currently have Voice Mail Plus by TEK Data Group
but it seems to be slow, and goes down to much for our taste.  I don't
frequent this group so if this is in the FAQ just mail me a copy of
that.

We have:
  50 active voice mail boxes
  AT&T System 75  (PBX)
  AT&T Voice Bridge
  Talco Research  TRU System  to record PBX information
  TEK Data Group  Voice Mail Plus V 1.528

The rest of the system is fine, just the voice mail we want to investigate.


Thanks in advance,

Samantha Star Straf      [e-mail]

------------------------------

From: [e-mail] (Dan Chang)
Subject: International 800 Taboo?
Date: 11 Feb 1994 18:55:03 GMT
Organization: Jet Propulsion Laboratory


I've heard reports of various levels of detail that it is difficult to
set up an 800 number which people outside the US can call to. A quick
sampling of customer service numbers for various products in my office
seem to support this -- usually an 800 number is given for US and
Canadian callers only.

I assume this is the result of policy (possibly of foreign governments?)
and not of technical infeasibility.  Does anyone know any more details?
Do the various IXC's have a single policy in place, or do they have a
hodge-podge list of countries from which 800 calls are permitted/not
permitted?


D. Chang


[TELECOM Digest Editor's Note: Only a few countries forbid collect
call service to the USA (including automatic collect service, which is
what '800 numbers' are). What is more likely is that the owners of
800 numbers do not want to pay the high cost of calls from international
points, which is understandable in many cases. Many of the numbers in
your sample are companies which for whatever reason only do business in
the USA and/or Canada; they have no reason for or interest in calls
*which they have to pay for* from outside our boundaries. There are
numerous international '800 numbers' which terminate in the USA. If you
want one, you can have one except in the few instances noted at the
beginning of this response. Bear in mind that the number in the other
country will resemble the numbering system *there* instead of here;
that is, it may be listed as 0800 or 119 or whatever that country uses
for *its* 'toll free' or automatic reverse charge call prefix (just as
we use 800 here). But dial that number and it will ring in the USA
just as many 800 numbers dialed here actually terminate in Europe or
Japan (even though from the other end they would have a different
number sequence for the same thing.) Most countries are pretty friendly
with each other where telecom is concerned. There is no 'taboo' as
you phrased it.   PAT]

------------------------------

Date: Fri, 11 Feb 1994 14:26:05 -0500
From: [e-mail] (Rubens Rahim)
Subject: AT&T Merlin vs. NT Meridien Norstar
Organization: University of Waterloo
Date: Fri, 11 Feb 1994 19:25:53 GMT


My company is considering purchasing a new system, and we are
considering the above two systems: The Merlin Legend and the Norstar.
We are getting Voice Mail with the System as well.

We are a small division (about 20 employees), But this office is
involved in Sales and Marketing, resulting in a large number of
incoming and outgoing calls.

We will not be installing an Auto Attendant. Most of our customers would
find that annoying.

Does anyone have any positive/negative experiences with either system
in terms of functionality and upgradability? Reply E-mail or to news.


Thanks,

Rubens Rahim
#3-113 Westmount Rd. N.
Waterloo, ON, N2L 5G5
[phone]

------------------------------

Date: Fri, 11 Feb 1994 13:43:00 +0000
From: brahmananda (b.) vempati <[e-mail]>
Subject: Seeking Information Regarding UPT Standards Draft


Is it possible for me to get hold of some information regarding UPT
(Universal Personal Telecommunications) standards that are in the
process of being drafted?

If so, how do I go about getting to them?

Any information/leads regarding this would be greatly appreciated.


Thanks,

Bujji    [e-mail]

------------------------------

Date: Fri, 11 Feb 1994 16:33:20 CST
From: [e-mail]
Subject: Re: Don't Trust The Phone Company


In TELECOM Digest V14 #73, Pat wrote:

> [TELECOM Digest Editor's Note: Oh, I believe you. It could be that
> whoever called the lady quickly call-forwarded his line to yours
> immediatly after disconnecting; he woke her up with his call, she sat
> there in a just-awakened stupor and thought about it for a minute then
> used 'return last call' to reach you via him. This is where having
> Caller-ID *and* 'return last call' both on the line would be useful.
> That way one could see the actual number placing the call even if the
> return trip led somewhere else. Maybe there ought to be a dialing code
> for the purpose of 'do not forward'. That is, the person placing the
> call would dial some two-digit code (such as for blocking or do not
> disturb) which meant 'absolutely ring number such and such'. This would
> be sort of like the post office endorsement we can use on letters which
> says, 'do not forward, return to sender if unable to deliver as addressed'.
> Telco's response would be to ring that number or respond with a voice
> intercept, 'cannot ring that number now' if the number was being for-
> warded. There may be times, for example, when I wish to speak with you
> but not if I know you are elsewhere; in those cases I am willing to wait
> until you are at home. The recipient's Caller-ID box would show some
> notation such as 'forced delivery from xxx-yyyy' to indicate a call had
> been received but not forwarded at the caller's request.  PAT]

   The TCAP (Transaction Capability Application Part) of SS7 is used
what makes the 'return last call' feature work.  It boils down to
queries and responses between the originating and terminating switches
(is the terminating party idle?; if not notify me when he is; etc.).
TCAP defines a parameter called the 'call forwarding active parameter'
which indicates if any call forwarding features are active on a line.
If call forwarding or selective call forwarding is active, than
'return last call' is denied.  Here in Lincoln, we have DMS-100's,
GTD-5's, and a 5ESS; that's the way the feature worked when it was
tested in our network.

   Without knowing more about the networks involved in these obscene
phone call scenarios, I would be reluctant to theorize what is going
on. I do know that humans are a lot more unpredictable than switches;
they are also more creative when they want to be :-)


Curtis R. Nelson, P.E.      email:    [e-mail]
Lincoln Telephone Company   phone:    [phone]
1440 'M' Street               fax:    [phone]
Lincoln, NE  68508

------------------------------

Subject: Re: Don't Trust The Phone Company
From: drharry![e-mail] (Alan Boritz)
Date: Fri, 11 Feb 94 06:34:15 EST
Organization: Harry's Place BBS - Mahwah NJ - [phone]


[e-mail] (Kyle Rhorer) writes:

>> In RISKS issue 15.46, Tom Bodine reports the unsettling experience of
>> being accused of making an obscene phone call, after the husband of
>> the recipient of the call (his wife's best friend) used the "call
>> return" feature at the end of the obscene call, and then reached his
>> number.  He speculates that his number was captured by the friend's
>> telephone switch as the result of a failed call from his wife while
>> the friend's line was busy with the obscene call.

> I live near the Bell/GTE border in my part of the world, and it is
> obvious that the two companies talk to each other only when required
> to by law.  More specifically, I can not "call return" a call that
> came from a GTE caller, even if that caller is less than a block away
> from me.  Is it possible that Mrs. Bodine was the last caller *before*
> the obscene call, and the obscene call came from a subscriber in a
> different operating company?  Perhaps the OC that serves the Bodines
> simply doesn't update the call return register if the call is from an
> "unidentifiable" source?

Or the register is not updated BEFORE the call goes through?  I can
get the same effect if I pick up the phone before the caller-id data
is sent between the first and second ring (my caller-id box won't pick
up the data, therefore the "last caller" info is not updated.

However, would the original writer know if the victim's husband used
the TELCO call-return feature, or a Caller-ID box's call-return
feature.  Some people (when relating a story like this) may not know
enough to differentiate the two.


[e-mail]  or  uunet!drharry!aboritz
Harry's Place BBS (drharry.UUCP) - Mahwah NJ USA - [phone]


[TELECOM Digest Editor's Note: Well if the victim's husband read the
number off of the Caller-ID box and used its call-return feature, then
I'd say Mr. Bodine has got a bit of a problem. If he used telco's same
feature out of the switch instead, then who knows ...  PAT]

------------------------------

Date: Fri, 11 Feb 1994 14:15:22 +0100
From: [e-mail] (Robert Hettmansperger)
Subject: Re: Don't Trust The Phone Company
Organization: Bellcore


In article <[e-mail]>:

> In RISKS issue 15.46, Tom Bodine reports the unsettling experience of
> being accused of making an obscene phone call, after the husband of
> the recipient of the call (his wife's best friend) used the "call
> return" feature at the end of the obscene call, and then reached his
> number.  He speculates that his number was captured by the friend's
> telephone switch as the result of a failed call from his wife while
> the friend's line was busy with the obscene call.

By Bellcore's requirements, the record of the last incoming call
should NOT be updated if the incoming call is given busy treatment
[TR-227, Appx A].  It SHOULD be updated if it is given call-waiting
treatment.

> While such a feature interaction is possible (is the number supposed
> to be captured on a busy? I know it is on a no-answer failure), there
> is another way for this to occur: The perpertrator may have applied
> the call forwarding feature on his own phone prior to making the call,
> and left it there for a bit afterwards.

By Bellcore requirements, if "return call" is applied to a number
which is in turn forwarded to another number via Call Forwarding
Variable, the call should NOT be allowed to go through [TR-227, Sec
3.8G].

Also FYI, on forwarded calls, the CallerID delivered is supposed to be
the number of the original caller, not the number of the forwarding
station [TR-31, 3.8F].

Of course, this is what Bellcore requires on paper.  What you find in
the real world may differ due to switch manufacturer noncompliances or
bugs.


Bob Hettmansperger   Bellcore CLASS Requirements

------------------------------

Date: Fri, 11 Feb 94 09:23:45 EST
From: [e-mail] (Tom Olin)
Subject: Re: Don't Trust The Phone Company


Do all older switches still in use support whatever is needed to make
call return work?  If not, what happens to the last stored number when
somebody calls from such a switch?


Tom Olin        PAR Technology Corporation   Voice: [phone] Ext 638
[e-mail]           New Hartford, NY     Fax: [phone]


[TELECOM Digest Editor's Note: What happens around here is that any
instance of a new call arriving zaps whatever was in the buffer before
it. A good number could have been there, then a call comes from out of
LATA or an unequipped office or whatever ... the buffer is zapped.
Attempts at that point to 'return last call' result in an intercept
'we are unable to return a call to that number'. Nor will it tell you
what the number was, because of course it does not know the number. If
it did, it would be able to return the call.  I think also there is
only one buffer which holds either 'last number dialed' or 'last call
received' but not both. If I dial a number and get a busy, I can then
use a star code to have the system attempt to reach it (once it
becomes unbusy). But if a call comes in in the meantime (before I use
the star code to activate the repeat dial process), all of a sudden
the switch has no idea what I am talking about when I try it after the
call (I received) in the interim. Furthermore, here the 'repeat dial'
and 'return last call' memories are both zapped at the same time by
the use of *86. That is, when I dial *86 the message in reply is 'your
repeat dialing *AND* automatic callback requests have been cancelled.'
*66 is to 'automatic callback' (of calls you receive) while *68 is to
'repeat dial' (calls you place) or whatever they call it. On the other
hand, *86 and *88 both do the same thing: either code cancels BOTH
numbers from memory. PAT]

------------------------------

Date: Fri, 11 Feb 94 14:21:10 EST
From: Charles Reichley <[e-mail]>
Subject: Re: Don't Trust The Phone Company
Reply-To: [e-mail]
Organization: IBM Federal Systems Company (for now)- Manassas, VA USA


In a note to a post by Monty Solomon <[e-mail]>, Pat writes:

> [TELECOM Digest Editor's Note: What seems to put a fly in the ointment
> where the arguments about false identification due to a variety of
> possible causes (one call arrived when line was busy, next call went
> in the 'return call' buffer, etc, call returned to the wrong party of
> the two who called about the same time) is Mr. Bodine's comment that
> this woman had received *several* obscene calls over a period of time.
> Surely the intricacies of the modern phone network did not interact
> in such a bizarre way every time. If there have been so many obscene
> calls, can't the woman at least identify the voice of the caller, or
> listen to Mr. Bodine's voice and qualify or disqualify him as the
> person responsible?   PAT]

We were not told if there was a voice recognition.  Nobody is arguing
that the woman didn't receive phone calls.  The only argument is over
the ONE time that they used call-return to see who the obscene caller
was.  It is quite possible that Tom's wife had just called her friend at
this time (Tom's wife would know this, so for it to be a lie the lie
would have to be perpetrated by both Tom and his wife, against what is
said to be his wife's best friend).

It seems like a coincidence, but they do happen.  Yesterday in my
workplace a co-worker picked up a phone and heard a voice, so he hung
up (Some of our phones are on the same phone line).  He asked me if
that particular phone was shared, and I told him no.  So he went back
and picked it up, heard talking again, and hung up.  He said it must
be shared, someone is on it.  I picked it up and got a dial tone. Three
minutes later a guy walked into the lab, and asked who was hanging up
on him.  It turns out he had dialed the phone TWICE, and BOTH TIMES we
had picked up the phone before it rang.  Quite a coincidence to happen
twice, but it did.  >


Charles W. Reichley,   Loral/FSC???, Manassas, Va.

------------------------------

Date: Fri, 11 Feb 94 13:30:26 CST
From: [e-mail]
Subject: Re: Remote Call Forwarding to Priority Ringing
Organization: AT&T


In article <[e-mail]> [e-mail] (Steve
Cogorno) writes:

> Said by: Robb Topolski KJ6YT

>> I have remote call forwarding.  Can I set priority ringing to
>> my remote call-fowarding number so when anyone calls me via that
>> number I get the distinctive ring?  Or is the calling number reported
>> to the feature the caller's actual number rather than the forwarder's
>> number?

> If you are in Pacific Bell land, the answer is no.  Pacific Bell says
> that the two features are incompatible and they will not interact;
> something about the mode in which the SS7 protocol identifies the
> originating number when RCF is involved.  Interestingly enough, all
> other types of diversion (Busy/No Answer/Call Forwarding) will function
> as you describe with Remote Call Forwarding.

   Well, I'm confused.  TR-TSY-000031 says the Originating DN should
be displayed at the "remote" station when forwarding via CF Variable,
CF Don't Answer and CF Busy Line.  TR-TSY-000219, "Distinctive Ringing..."
also says the Originating DN should be used for determine ringing
pattern "If a call has been forwarded".  (There is no mention of RCF,
but that's not unusual.)

   So these (and all other) CLASS features always use the Original DN
for their operation, and are unaffected by forwarding.

   Certainly, RCF is treated, so far as I can tell, almost exactly
like the CFV case in AT&T's switches.  (In fact, the LSSGR description
of RCF says it's just like CFV, except .... and doesn't list Calling
Number Delivery or Distinctive Ringing features as one of those
differences.)

   So just how is RCF "not interacting" with Distinctive Ringing?  I
agree it will not work as Robb wishes -- but it is working EXACTLY
like a CFV number, correct?


Al Varney

------------------------------

From: [e-mail] (Steve Cogorno)
Subject: Re: Remote Call Forwarding to Priority Ringing
Date: Fri, 11 Feb 1994 00:29:56 PST


Said by: Mike King

> Why not get Ident-a-Ring, or whatever your LEC calls the service where
> more than one directory number is assigned to your line, and then have
> the RCF number point to the additional phone number?  Presto.  Your
> RCFed calls will always have a distinctive ring, regardless of whichever
> number gets forwarded.  This would even work if the exchange with your
> RCF number isn't equipped with SS7.

Because Pacific Bell doesn't offer that service.


Steve  [e-mail]
#608 Merrill * 200 McLaughlin Drive * Santa Cruz, CA 95064-1015

------------------------------

End of TELECOM Digest V14 #76
*****************************