Inbound call handling is the most complicated part of the HylaFAX
software.
This is because modems vary so widely in the way they process inbound
calls for fax, data, and voice use.
Also, inbound calls typically require that a modem be configured
before a call is received and many modems do not accept
commands from the host until after a call has been recognized,
accepted, and processing initiated.

HylaFAX handles inbound calls in the faxgetty program.
The modem is initialized as <A HREF="#ModemSetup">described above</A>
and faxgetty then waits for a ring status message from the modem.
On receiving input from the modem the following processing takes place:

The modem is locked. If the modem cannot be locked
because there is an outbound user in control of the modem then
it is released and faxgetty will wait for the lock file
to be removed.

Wait for RingsBeforeAnswer rings, waiting at most 5 seconds
for each ring status message.
If distinctive ring support is configured (RingFax,
RingData, and RingVoice) then the ring status
messages are checked and the type of call is potentially deduced.
If Caller-ID support is configured (CIDName and
CIDNumber), then any Caller-ID information returned by the
modem is parsed.

If the appropriate number of rings was not received, then the
line is hung up and the modem is reset and initialized.

Check any Caller-ID information. If QualifyCID is configured
and the caller is not acceptable, then reset and initialize the modem.

If the call type is already known from distinctive ring information, then
the call is processed immediately. If faxgetty was instructed to answer
any type of call, then the call is answered as appropriate.
However, if a particular type of call was to be processed (e.g. data)
and the deduced type of call does not match, then the call is
rejected and the modem is reset and initialized.

If the call type is unknown then the call is answered according
to the the current type specified by
AnswerRotary and AnswerRotor.

If the call is not successfully answered and if AdaptiveAnswer
is enabled, the next item in the AnswerRotary list is used
to immediately re-answer the call. This is repeated until a call
is successfully answered or the list of choices in AnswerRotary
is exhausted.

Call answering is done as follows:

Send the modem one of
ModemAnswerDataCmd,
ModemAnswerFaxCmd, and
ModemAnswerVoiceCmd according to whether the call is to
be answered as data, fax, or voice, respectively.
If any of these are not set then ModemAnswerCmd is used instead.

Wait for a response from the modem that signifies carrier has
been established and which identifies the type of call.
The exact set of responses is given in
<A HREF="man/hylafax-config.html">hylafax-config(4F)</A>.

If ModemWaitForConnect is enabled, then HylaFAX will read
responses from the modem until a CONNECT response is sent
to the host or an error is detected; e.g.

Host Modem
ATA -->
<-- DATA
<-- CONNECT

If a call is successfully answered, then one of
ModemAnswerDataBeginCmd,
ModemAnswerFaxBeginCmd, and
ModemAnswerVoiceBeginCmd,
is sent to the modem according to the call type deduced above.
This mechanism is useful for modems that automatically change
DTE-DCE communication to a fixed line speed or flow control setting
for inbound facsimile calls.

At this point the call has been answered, carrier established,
and the call type is known.

Data calls are handled by invoking a system getty program; but
only if the GettyArgs parameter is set.

Voice calls are handled by invoking a system vgetty program; but
only if the VGettyArgs parameter is set.

Facsimile calls are handled directly in faxgetty.

For a data or voice call faxgetty forks and execs the appropriate
program. The UUCP lock file is setup so that it is owned by the
child (important for SLIP and PPP) and the parent handles cleanup
of various resources when the child process terminates.