Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!wuarchive!brutus.cs.uiuc.edu!apple!bionet!hayes.fai.alaska.edu!accuvax.nwu.edu!nucsrl!telecom-request
From: AMillar@cup.portal.com
Newsgroups: comp.dcom.telecom
Subject: Re: Telephone Diverters
Message-ID: <10819@accuvax.nwu.edu>
Date: 12 Aug 90 21:51:44 GMT
Sender: news@accuvax.nwu.edu
Organization: TELECOM Digest
Lines: 67
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 567, Message 3 of 11


dave%westmark@uunet.uu.net <10707@accuvax.nwu.edu>, Dave Levenson 
writes:

>What in the world is "reverse modem detection"?  

In normal modem operation, the originating modem dials the phone and
is silent until it sees a carrier presented by the answering modem.
The answering modem detects a ring, goes off-hook, and sends a carrier
to the originating modem.  Then they go through their "connection"
business to figure out if the other end is Bell 103 or 212A or
whatever.

An alternative mode of operation is available in my Micom-brand US$99
Hayes-clone modems.  As part of the dialing command, there is a
specifier to make the _originating_ modem produce a carrier after it
dials, as if it were answering a call.  The modem that is being called
must pick up the phone as if it were making a call, and it will hear
the carrier given by the calling modem.

Reverse connections are no big deal in a manually-dialed call, because
manual modems just have an originate/answer switch, and you flip it on
both ends.  In an automated Hayes-command environment, you have to
change the way your software interacts with your modem.  On my Micoms,
the calling modem requires pause commas after the phone number in the
"ATD" dialing command to wait for the call to go through.  A letter
"R" as the last part of the dialing string tells the modem to produce
carrier instead of looking for it.

On the answering end, I have not figured out any way to do
auto-answering in originate mode with these modems.  So, the software
waits for the "RING" message from the modem, and then does a dial
(ATD) command with no phone number.  The answering modem thinks it is
dialing a call, picks up the ringing phone line, and then detects the
carrier produced by the calling modem.  They do their "connect" thing
and everybody is happy.  There may be other modems that will
auto-answer in originate mode, and mine may even do it (I just haven't
bothered to pursue it).

So ... Why would anybody want to do this?  The first situation is the
fax/modem switch-box, where the switch-box looks for modem carrier
produced by the calling modem and transfers it to the answering modem.
I use it for a modem on my company's PBX with Octel Aspen "automated
attendant" call direction.

There are no DID lines to people's desks at work.  To reach an
extension without going through a human operator, you call a main
number that is answered by Aspen.  You give it a touch-tone extension
number, and it transfers you to that extension.  The problem is that
when the person picks up their phone, they get a message from Aspen
saying "Transfer... Transfer..." and it takes fifteen seconds or so
for you to get put through.  It's no big deal on the voice side, but
when you are a modem calling, and the answering modem picks up the
line, it presents its carrier to the "Transfer..."  message and by the
time you get through, it's too late.  With the reverse-originate
setup, I can put in a delay which waits long enough for the real
end-to-end connection before doing carrier.  (You may ask why I didn't
go for a direct-line to the outside.  This way, the modem can be
called from any internal extension and take advantage of tie-lines
between sites.  Besides, it's one less trunk to pay for... :-)

The whole thing sounds like a pain, I know, but it takes longer to
explain it than to set it up (as long as you can customize your
software on each end).  It works here!


- Alan Millar    AMillar@cup.portal.com