[comp.dcom.telecom] Call Forwarding Capacity

Patrick_A_Townson@cup.portal.com (07/29/88)

Responding to the item on 'how many calls can be forwarded at one time',
JSol notes when he got his Remote Call Forwarding lines he was told he
could choose how many calls to forward at one time.

What telco meant was, you can choose *how many paths you would like to
pay for*, and each path thus purchased will allow one more call to be
forwarded simultaneously.

Unlike Call Forwarding, Remote Call Forwarding is a business offering where
a line terminates in a central office, with no physical wires going to
a customer's premises. This phantom number in the central office is programmed
to always forward calls to wherever, at the direct dial rate in effect at the
time a call is received. The subscriber has no control over the programming
of the forwarding. It has to be done when the line first goes in, and it
stays that way until the service is discontinued. Typically one call at a
time can pass through to some end destination via the remote number.

In 'regular' Call Forwarding here in Chicago, there is no limit to the
number of calls which can be forwarded at one time except for the capability
of the final or end destination to receive the calls. In other words, if
the end destination has ten lines in rotary, and you forward your calls to
the first number in that hunt group, then ten people could call through your
number to the end number all at the same time.

This is not a universal thing. I think we have one or two prefixes here in
Chicago using older versions of software which do not allow unlimited call
forwarding.

On the same subject, some of our prefixes here allow 'chain forwarding', while
others do not. In chain forwarding, A forwards to B, B to C, C to D, and D to
E. A call arriving on A is bumped along to B then C then D then E in a matter
of an extra couple seconds or so. The only limit to chain forwarding is a
practical one: The transmission gets very poor after 2-3 links.

But the software in some of our central offices does not allow this. A can
forward to B, and B can forward to C.....but a call dialed to A will still
force its way onto B, and go no further, despite B's forwarding to C. And
a call to B will forward to C *provided B was dialed direct*, and was not
reached as a result of getting forwarded from A!  Is all that clear?

Its as though there were two ways to approach a line (1) by direct addressing
of that number or (2) indirectly due to someone else forwarding. I don't
think we have too many of this latter type left here.

And what happens if A forwards to B and B forwards to A? In the past, it
was allowed, and a call to either number would forward to the other number
and ring through. The endless loop A to B and B to A seems to imply did not
in practice exist. Some offices were programmed that A/B/A type forwarding
would result in a busy signal for persons calling either number. Now the
very newest software here prohibits that type of forwarding if the forwarder
is in your same office. If A is forwarded to B, then attempts by B to
enter *72-A will be met with a re-order tone, or possibly a 'your call
cannot be completed as dialed' type message. Illinois Bell has also
of late changed the software to prohibit forwarding to any 1-900 number,
any 976 number, 911, 555-1212, any 950-xxxx number and a few others.
The attempt will be blocked after dialing *72-976 or *72-1-900 for
example.

Question for the experts: If your phone is forwarding somewhere, you can
use your phone to dial your own number and get forwarded to wherever.
Why is it *when not on forwarding* that dialing your own number results
in a busy signal instead of a 'call waiting' signal?

Curiosity on my own phone lines: I have two lines, which hunt each other
on busy or no answer after three rings. Both lines have call waiting as
well. Due to call waiting, neither line is 'truly busy' for the purpose
of getting the hunt feature to work...with one exception. If I enter the
*70 sequence to cancel call waiting and then dial my own number, the
other line will ring, and the call will hunt to the second line. If however
I merely have two calls on the line, talking to one and holding the other,
then the busy signal kicks in and the third call does not hunt to the other
physical line.

Its as though there were also different types of busies: engaging *70 at some
point in a call creates one type of busy the central office recognizes as
a situation where it should hunt another physical line, and simply being
off hook, dialing your own number, or having two calls on one line via call
waiting which it considers to be something other than a 'regular busy signal.'

Does anyone have any ideas on this? Is it just a function of how the software
is set up office by office?

Patrick Townson

clark@beaver.cs.washington.edu (Roger Clark Swann) (08/05/88)

>From Telecom Digest Volume 8, issue 119
 Patrick Townson writes:


>On the same subject, some of our prefixes here allow 'chain forwarding', while
>others do not. In chain forwarding, A forwards to B, B to C, C to D, and D to
>E. A call arriving on A is bumped along to B then C then D then E in a matter
>of an extra couple seconds or so. The only limit to chain forwarding is a
>practical one: The transmission gets very poor after 2-3 links.
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

What???   Why???   How???

If A,B,C,D,E are in the same ESS office, Then the number of chains in
the the forwarding should have nothing to do with the quality of the
transmission since the controller looks up the forwarding route and
tells the switch matrix to make the right *end* connections. In this
case it would be connect A to E ( one link ). Now if A,B,C,D,E are
located in different offices, then the chaining may effect the
quality since the call would progress through each office in the
chain. However, I would be surprised if one could notice a
reduction in quality through only 3 ESS type offices...


Am I totally washed up here or what???
Maybe someone that knows ESS system architecture could comment one
the above...

Roger Swann	uucp: uw-beaver!ssc-vax!clark