Busy Connect

I don't know how many other small/dialup ISPs are seeing this problem.
BellSouth just turned it on in our area. Sent our support calls through
the ceiling during busy evening hours.

I was wondering if anybody out there had any insight into how functionally
integrated once seperate networks become when two telcos merge or one
telco buys anothers network. I was looking at a recently publiched map of
Cable and Wireless's new network, since the purchase of MCI's network as
an off shoot of the MCIWorldCom merger, and the map did not seem to
include
C&W's old network topology. In fact it seemed pretty close to being the
old MCI network back when they released the topology and things were not
top secret. The question is what will become of the old C&W network, will
it be
functionally integrated within routing tables and meshed with the MCI
network or operate as a seperate privately peered network. Any input would
be greatly appreciated.

Thanks,

Sean Gorman
University of Florida
Department of Geography

Busy Connect ...

The user will not actually get charge for a busy connect service. When
he reaches a busy line, instead of getting a busy signal, he will get a
prompt to th effect "if you want the phone company to call you back when
the line is free ... for a 75 cents charge ... press 1 is yes, and 2 for
no". So, you modem user should not be charge when it encounter that
situation.

As with your users complaining getting "no answer", well, it is really a
case of swapping of the failure code of "busy" to "no answer". In
either case, they are out of luck ... because pressumably you do not
have enough circuits into your dialup POP, or the ILEC/CLEC has capacity
problem ... hence the busy situation.

Regards,
John Leong

We've had the same up here in Canada for a while now, very
annoying for customers. Anyhow, if you do *02 (Bell here uses DMS), it
disables it forever (we'll until you do *02 again). We've actually put
that message on our TechSupport quick tips music when you call in to
report a problem... Why does technology have to be so annoying sometimes
:slight_smile:

  Later

Cyril Jaouich [CJ837]

> Busy Connect ...

The user will not actually get charge for a busy connect service. When
he reaches a busy line, instead of getting a busy signal, he will get a
prompt to th effect "if you want the phone company to call you back when
the line is free ... for a 75 cents charge ... press 1 is yes, and 2 for
no". So, you modem user should not be charge when it encounter that
situation.

Depends on the phone company, doesn't it?

As with your users complaining getting "no answer", well, it is really a
case of swapping of the failure code of "busy" to "no answer". In
either case, they are out of luck ... because pressumably you do not
have enough circuits into your dialup POP, or the ILEC/CLEC has capacity
problem ... hence the busy situation.

Yes, but look at it from the point of view of a customer who (a) doesn't
know what happens behind the scenes and (b) probably isn't listening to
his modem dial the phone. "No answer", to me, as an ISP customer would mean
that there is a broken modem somewhere that is not answering the phone.
Definitely different than "Busy."

"No answer", to me, as an ISP customer would mean
that there is a broken modem somewhere that is not answering the

phone.

Definitely different than "Busy."

The modem return code, unfortunately is often not precise. After
dialing, if it gets any voice response, be it some human answering
because of mis-dialed, message from the phone company offering to retry
when line is free, annoucement of "As of <day>, the area code you called
will be change to <XXX>", and finally annoucment of "All circuits are
busy, please retry latter" ... all will result in a "no answer" return
code as the modem expects and not getting the commencement of the modem
hand shake sequence.

All such voice reponses have nothing to do broken modem ... and the last
case is actually a busy condition that cannot be correctly handled by
most modem (the Courier has the capability to return a "voice" return
code ... but cannot, for good reason, tell you what is the nature of the
voice message).

This had been a pain in the rear end to me in my previous project. I
will be happy to share with anyone my experience with modems ... but
let's take this off line.

Best Regards,
John Leong

You can say _that_ again.

this is rapidly veering off topic, so replies privately, please, but
does _anyone_ know why 15 years after Bell standardized on different
SIT tone sequences for differen error conditions, modems _still_ can't
report the proper error?

Cheers,
-- jra