Handbook:Basic Server Configuration:Starting Inbound Service

To setup HylaFAX for inbound facsimile or data service a modem configuration file must be setup and a faxgetty program must be started to listen for input on the tty device. The configuration file setup is usually done at the same time that outbound service is configured; i.e. when faxaddmodem is run. A faxgetty server for the modem should be setup to be run by the init(1M) process according to local system conventions. For System V-based systems this is done by editing the /etc/inittab file to spawn faxgetty on the appropriate port. For example, if a modem is to be started on /dev/ttyf2 the following line might be appropriate:

t2:23:respawn:/usr/local/sbin/faxgetty ttyf2

For systems that use a BSD-style setup the following line might be appropriate for the /etc/ttys file.

cuaa0  "/usr/local/sbin/faxgetty"    dialup  on

Note that faxgetty may be run on a modem port whether or not it is to provide inbound service. By setting the RingsBeforeAnswer configuration parameter to zero, faxgetty will not answer an incoming phone call unless it is explicitly commanded to by the faxanswer(1M) program. This may be desirable if a phone line is used, for example, as the primary line for voice calls.

In general it is desirable to run faxgetty because faxgetty informs the HylaFAX scheduler process whenever modems are in use and because it identifies modems' capabilities (passing them on to the scheduler so that it can make informed scheduling decisions). faxgetty also includes support for screening calls based on caller-ID information (consult the section Caller-ID Support) and for automatically routing calls based on distinctive ring when these services are provided by the local PTT (consult the section Distinctive Ring Support). For this additional functionality, and because faxgetty does a reliable job of reseting and configuring recalcitrant modems, it may even be desirable to run faxgetty on non-fax modems.

The following sections discuss HylaFAX™ support for servicing particular types of inbound calls.

Inbound Facsimile Service
In normal operation HylaFAX's faxgetty process will automatically answer inbound phone calls and receive facsimile. Received facsimile are written to files in the recvq directory in the spooling area on the server machine. Facsimile data is stored as a TIFF Class F (TIFF/F) file and protected according to the RecvFileMode configuration parameter specified in the modem configuration file. The RecvDataFormat configuration parameter can be used to control the encoding of data stored in these files; consult the section on Transcoding of Received Facsimile for more information on this facility. The maximum number of pages that will be received in a single call can also be controlled with the MaxRecvPages configuration parameter. Finally, HylaFAX provides an access control list mechanism for restricting recived facsimile according to the TSI string passed as part of the facsimile protocol; consult the section on Rejecting Junk Facsimile for more information.

Inbound Data Service
By default HylaFAX does not enable support for inbound data calls. Data service is not enabled so that naive users do not accidentally setup inbound access to their system before proper password controls are in place. To enable inbound data service the modem configuration file must be setup to accept data calls and to invoke the normal system getty program to process the incoming call. Normally this involves enabling the use of adaptive-answer functionality and the setup of the GettyArgs parameter in the configuration file.

Adaptive answer is the ability for a modem to determine whether an incoming phone call is for data, fax, or voice use. If a modem supports a good adaptive-answering facility then it should be enabled with the ModemSetupAACmd and the faxgetty process will automatically service fax, data, or voice calls as identified by the modem. Most Class 2 and Class 2.0 modems provide adaptive-answer support that distinguishes data calls from fax calls and the prototype configuration files that come with HylaFAX automatically enable it if it is provided by the modem. Most Class 1 modems do not provide adaptive-answer support, but HylaFAX provides adaptive-answer support in the server. Consult the section on Adaptive Answer Support in the next chapter for help on configuring adaptive-answer support.

Setting up the GettyArgs parameter requires an understanding of how to automatically startup the system getty program. HylaFAX will invoke the getty program when a data call is recognized and set up the standard input, output, and error descriptors to point to the appropriate tty device. The getty program should not reopen or reinitialize the modem before doing its work. Some getty programs are incapable of this and are unsuitable for use with HylaFAX. The parameters passed to the getty program must also identify the speed to use to communicate with the local modem. Some getty programs want to automatically detect this rate based on the CONNECT message that a modem sends to the host when a connection is established; these programs are unsuitable for use with HylaFAX. A getty program used with HylaFAX must be able to handle a fixed speed for host-modem communication, with the speed specified on the command line.

For System V-style getty programs the appropriate parameters are typically of the form:

GettyArgs: "-h %l dx_%s"

where the -h parameter instructs getty to not hangup the device first, the %l parameter is translated to the device name (``the tty line''), and the dx_%s parameter identifies the /etc/gettydefs entry to use (%s is translated by HylaFAX™ to the speed used to communicate with the modem). Note that the exact parameters to supply depend on the getty program used; consult local documentation to understand what options should be used.

For BSD-style systems, GettyArgs is usually of the form:

GettyArgs: "std.%s -"

where std.%s refers to an entry in the /etc/gettytab file for a fixed speed port; e.g.

g|std.19200|19200-baud:sp#19200: h|std.38400|38400-baud:sp#38400:

(Note that as before, the ``%s'' is replaced by the speed for host-modem communication.)