Difference between revisions of "Handbook:Advanced Server Configuration:Configuration Parameter Usage During Modem Setup"

There are many configuration parameters that control the operation of HylaFAX in resetting and initializing a modem. This section presents these parameters and explains how they fit together in normal operation. By understanding how these parameters are used it is possible to control many aspects of the operation of HylaFAX.

In normal operation HylaFAX will first reset a modem and then prepare it for use with a setup procedure appropriate for the modem. Modem reset involves the following steps:

1. Lower the Data Terminal Ready (DTR) signal, pause ModemResetDelay milliseconds, and then raise DTR. DTR is used to force a modem reset rather than sending a command such as ATZ to the modem because many modems can get confused and enter a state where commands sent from the host are ignored. Instead HylaFAX uses a hardware control signal to force the modem to do a reset operation. This usage requires that a modem respond to a DTR transition by resetting itself. Since modems all take different amounts of time to do a reset operation the time that HylaFAX waits for the modem to complete the reset operation is programmable. A certain Hayes Technical bulletin claims one should wait 2.6 seconds for a modem to complete a reset operation. In practice this is much longer than most modems need and this parameter can be reduced with a significant speedup in the overall setup process.
2. Once the modem has been reset (assuming the modem monitors DTR and does the "right thing" in response to DTR being lowered), HylaFAX sets up the baud rate and flow control parameters for the tty device using the ModemRate and ModemFlowControl parameters.
3. HylaFAX then flushes any data received from the modem since the reset and sends the following sequence of commands:

ModemResetCmds          any additional reset commands
ModemEchoOffCmd         disable modem echo of commands
ModemVerboseResultsCmd  enable verbose result codes
ModemResultCodesCmd     enable transmission of result codes
ModemNoAutoAnswerCmd    disable modem from auto-answering calls
ModemOnHookCmd          place modem ``on hook
ModemPauseTimeCmd       configure delay for "," in dial string
ModemWaitTimeCmd        configure time to wait for carrier
modemflowcontrolcmd     establish DTE-DCE flow control scheme
ModemSetupDTRCmd        force desired modem response to DTR transition
ModemSetupDCDCmd        force desired modem response to DCD transition 

Note that these commands are sent as two separate AT commands, broken between ModemOnHookCmd and ModemPauseTimeCmd; this is done to avoid problems with certain modems.

The reset sequence must be successful for HylaFAX to consider the modem in an acceptable state and to proceed with the subsequent steps:

1. Query the modem using ModemClassQueryCmd to verify it supports the functionality specified by the ModemType (this parameter can be used to control which class to use when a modem supports multiple classes).
2. Set the modem into the appropriate class using ClassXCmd, where X is one of 0, 1, or 2, depending on the application.
3. Identify the manufacturer, model, and firmware revision information using ModemMfrQueryCmd, ModemModelQueryCmd, and ModemRevQueryCmd parameters. This information is obtained early in the setup procedure in case special-case handling is required for the modem. Note also that for Class 1 modems it is typically not possible to query the modem for some of this information and it must instead be "hard-coded" in the prototype modem configuration file that is selected according to the product ID code returned by the ATI0 command.
4. Identify the modem capabilities using the ModemDCCQueryCmd for Class 2/2.0 modems, or according to the capabilities of the Class 1 driver and the result of AT+FTM=? and AT+FRM=? commands for Class 1 modems.
5. For Class 2/2.0 modems: establish whether the modem supports copy-quality checking and polled retrieval of documents; both these capabilities are automatically provided by the driver for Class 1 modems. If the modem supports copy quality checking, according to the result of the Class2CQQueryCmd and copy-quality setup commands are provided with the Class2CQCmd parameter, then the modem is setup accordingly.

Modem initialization is then carried out by sending the following commands to the modem:

Class 2/2.0 modems:

Class2Cmd 	force the modem into Class 2/2.0
Class2FlowControlCmd 	establish DTE-DCE flow control scheme
Class2TBCCmd 	select stream modem host-modem communication
Class2BORCmd 	set the bit order for HDLC and page data
Class2PHCTOCmd 	set the timeout during page transfer (Phase C)
Class2CQCmd 	enable copy quality checking
Class2NRCmd 	enable negotiation reporting (Class 2.0 only)
Class2PIECmd 	disable program interrupt handling (Class 2.0 only)
Class2BUGCmd 	enable HDLC frame reporting if requested
Class2DCCCmd 	initialize modem capabilities
Class2RELCmd+ 	enable reception of byte-aligned EOL codes
Class2CRCmd+ 	enable facsimile reception
Class2LIDCmd+ 	set local station identifier
ModemSetupAACmd+ 	enable adaptive-answer support

Class 1 modems:

Class1Cmd 	force the modem into Class 1
Class1FlowControlCmd 	establish DTE-DCE flow control scheme
ModemSetupAACmd 	enable adaptive-answer support

(Commands marked with a ``+ are optional and sent to the modem only if it is to be setup to receive calls.)

Flow control is explicitly set separately for Class 0 (data) operation and Class 1, 2, 2.0 (fax) operation. To configure the use of a different flow control scheme in each class simply override the default definition of the ClassXCmd parameter; e.g.

Class2Cmd: "AT+FCLASS=2<xon>"

Note however that this will only work for outbound usage; doing something similar for inbound processing is more complicated because the modem, rather than the host, decides when to switch between Class 0 and Class 1, 2, 2.0. Consequently HylaFAX must react to events rather than initiate them. This work is also complicated by the fact that many modems do not accept commands (or are confused by commands) from the host during certain critical sections of inbound call processing.