Handbook:Advanced Server Configuration:Modem Parameter Usage for Inbound Calls

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:

1. 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.
2. 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.
3. If the appropriate number of rings was not received, then the line is hung up and the modem is reset and initialized.
4. Check any Caller-ID information. If QualifyCID is configured and the caller is not acceptable, then reset and initialize the modem.
5. 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.
6. If the call type is unknown then the call is answered according to the the current type specified by AnswerRotary and AnswerRotor.
7. 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:

1. 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.
2. 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>.
3. 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




4. 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.

For fax operation faxgetty drops into the facsimile receive protocol.

More to be added.