Date: 7 Apr 1996 21:24:06 GMT
From: brian@nothing.ucsd.edu (Brian Kantor)
Newsgroups: comp.dcom.telecom
Subject: Re: Is Concurrent Call Forwarding Possible?

brettf@netcom.com (Brett Frankenberger) writes:

> Reminds me of an old story (which may or may not be true) about a
> college campus that had a PBX serving the dorm rooms ... some students
> figured out that if they forwarded extension A to extension B, and
> extension B to extension A, the switch would immediatly hang (or
> appear to hang -- actually, it was devoting 100% of its realtime to
> forwarding the call) and have to be restarted if anyone called A or B.

In 1986 it was an Ericsson MD110, and it was here at UCSD.  But it was
more complex than that:  the switch properly handled reflexive A<->B
forwarding correctly.

However, if you did A->B->C->A and dialed A, the switch would go away.
No dial tone, no display updates, nothing.  They fixed it by setting
the forwarding limit to once -- i.e, if you dialed A above, you'd
forward to B but not to C, even though B was set to forward further.

As far as I know, ten years later, that restriction is still in effect.
I don't know if it's still needed.  I rather think the switch software
would be smarter than that nowadays.

The first day of operation for a new phone switch is always lots of fun!


Brian


[TELECOM Digest Editor's Note: In the very early days of ESS here in 
Chicago back in 1973-74 they had Call Forwarding set up the same way
here. If A forwarded to B and B forwarded to C, then anyone who dialed
in to A stopped at B. Anyone who dialed B went on to C. The way it
was explained then was that A obviously wanted his calls to reach him
at B; he did not necessarily want C to be receiving his calls.   PAT]

Date: Tue,  9 Mar 93 15:21:19 CST
From: varney@ihlpl.att.com
Subject: Re: Number of Simultaneous Forwarded Calls
Organization: AT&T Network Systems, Lisle, IL

In article <telecom13.162.4@eecs.nwu.edu> rfranken@cs.umr.edu writes:

> This brings up an interesting question.  What would happen if such a
> loop were set up.  For example, suppose phone A forward to phone B,
> which forwards to phone C, which forwards back to phone A.  Assume no
> number of calls that can be forwarded at one time limits are in place.
> (i.e. assume that if X just forwards to Y, that there is no limit of
> how many calls can be forwarded, except that once Y runs out of trunks
> in the hunt group callers will get a busy signal).

   Brett, I hope you realize you are not the first person to think of
this question.  Every ESS(tm) switch in a college town probably had
this tried at least once before 1970.

> There are several cases, then:
 
> 1) A, B, and C are in the same switch.  The switch would then probably
> detect the loop and return a busy signal or stop forwarding and ring
> one of the phones.
 
   Bellcore suggests switches should detect the loop and block after
some number of forwardings, say five times.  The same DN should not
appear in two legs of the forwarding.  (This is for CFV --
customer-changeable call forwarding).  For RCF -- Remote Call
Forwarding -- they suggest a customer-specified number of simultaneous
forwardings be permitted.  They also hint that the default should be
one, except for cases where the customer has a multi-line hunt group
at the forwarded-to DN.  CF loop detection doesn't result in ringing
any telephone.

> 2) A, B, and C are in the same city, but off different switches (that
> are SS7 connected).  Would the loop be detected?  Does SS7 signalling
> tell the switch the entire path the call has taken? (i.e. when the
> switch for C got around to returning the call to A, would it know that
> the call has already passed through A?  The CNID field would be of no
> use since that would have the number of whoever started the loop by
> dialing A (say, D, for example), and the ANI field would be of no use,
> since that could contain B.  So, are there additional fields that
> would tell the switch that the call had passed through A?)

   Per Bellcore, ANI isn't passed in SS7 unless the call is
inter-LATA.  As you suggest, it's not useful in detecting the loop
anyway.  However, Bellcore's TR-972 (and ANSI T1) discusses the
parameters in SS7 that are created/modified by forwarding.  Of note:

  a) the Calling Party Number (CPN, your CNID) parameter is not changed
    when forwarding occurs in the switch,

  b) the Called Party Number (CDPN) parameter is changed to the forward-
    to number,

  c) if not present, parameters Redirection Information and Redirecting
    Number are added to the call; RI indicates how many forwardings have
    occurred so far and why this one occurred, RN contains the old CDPN,

  d) if those parameters were already present, the forwarding count in
    RI is incremented by the number of forwardings that occured in this
    switch, the RN updated with the last number that forwarded within
    the switch, and the RI gets the reason for the last forwarding.
    If not present, a parameter called Original Called Number (OCN) is
    added and receives the previous value of RN.  If already present,
    OCN is not modified.

   At any time, if the number of forwardings indicated by the total of
intra-switch and RI-indicated forwarding exceeds that allowed for the
DN currently forwarding (or a switch default, usually 10), the call is
routed to some tone.

   All of this not only helps the looping-forwarding problem, but also
permits Voice Mail and Answering Service systems to receive the first
and/or last forwarding number, thus identifying the "mailbox", even if
the client is located in another switch.  It also allows the systems
to know "why" the forwarding occurred, so "her line is busy" vs.
"no-one is answering" information can be given to the caller.

> 3) A, B, and C are in, say, Texas, California, and New Uork, off
> switches that have no SS7 connection to the IXC (if we are using
> Sprint or MCI, that would be no problem, and even AT&T has lots of
> places without SS7 connections to the LEC).  It would seem that the
> OLY information the IXC would then get would be ANI, which would be of
> no use in detecting that there is a loop.

> Do the IXC switches count calls in real time, and notice that there is
> a very large number of calls being made from A to B, for example, and
> then block A from calling B.

   I don't speak for any IXC (despite the Organization name), so I can't
comment on what they might do.

> It would seem, that in the abcense of SS7 connections reporting the
> entire forward path of a call, there would be NO WAY to detect such a
> loop positively.

   As I've indicated, one doesn't need the path -- just a count.

> I am not trying to be naive here ... I am assuming that I am not the
> first person to think of this, and that the telcos have a way of
> preventing this from occurring.  I guess my real question is how do
> they detect this?  By counting calls ...

   TELCos do not have cycles to burn in this manner.

> ...  Do all local telcos limit the number of
> simultaneous forwards at once?  (Although it would seem dangerous for
> an IXC to bet the stability of its network on every local telco
> remembering to set that parameter).  BTW, note that this loop would be
> free to the people involved, since there would never be supervision
> from the call being finally answered.

   The last statement is a clue.  The default (no parameters to forget
to set) in many switches is to allow only one forwarding from a given
number, UNTIL THE CALL IS ANSWERED.  This is why such things as call-
forwarding for un-answered calls (to Voice Mail, etc.) doesn't
absolutely guarantee that every call will be forwarded.  If a
forwarding occurs, say because of call-forward-busy-line while another
call is ringing, but the Voice Mail system hasn't answered when the
first call attempts to forward, the call will not complete.  If the
switch supports assignment of other than '1' for simultaneous
unanswered forwarded calls from a given DN, then the probability of
such happening can be reduced.  Such a tariff, if offered, is usually
more costly because of the added switch resources needed.

   Remote Call Forwarding is sometimes offered with a limit > one even
in switches that can't support CFV/CFDA/CFBL for more than one
unanswered call.


Al Varney - just my opinion, of course