HylaFAX Difference between revisions of "Handbook:Advanced Server Configuration:Modem Parameter Usage for Inbound Calls"
m (I've corrected some html syntax errors) |
|||
| Line 12: | Line 12: | ||
and faxgetty then waits for a ring status message from the modem. | and faxgetty then waits for a ring status message from the modem. | ||
On receiving input from the modem the following processing takes place: | On receiving input from the modem the following processing takes place: | ||
| − | |||
<OL> | <OL> | ||
| Line 18: | Line 17: | ||
because there is an outbound user in control of the modem then | because there is an outbound user in control of the modem then | ||
it is released and faxgetty will wait for the lock file | it is released and faxgetty will wait for the lock file | ||
| − | to be removed. | + | to be removed.</LI> |
| + | |||
<LI>Wait for <TT>RingsBeforeAnswer</TT> rings, waiting at most 5 seconds | <LI>Wait for <TT>RingsBeforeAnswer</TT> rings, waiting at most 5 seconds | ||
for each ring status message. | for each ring status message. | ||
| Line 26: | Line 26: | ||
If Caller-ID support is configured (<TT>CIDName</TT> and | If Caller-ID support is configured (<TT>CIDName</TT> and | ||
<TT>CIDNumber</TT>), then any Caller-ID information returned by the | <TT>CIDNumber</TT>), then any Caller-ID information returned by the | ||
| − | modem is parsed. | + | modem is parsed.</LI> |
<LI>If the appropriate number of rings was not received, then the | <LI>If the appropriate number of rings was not received, then the | ||
| − | line is hung up and the modem is reset and initialized. | + | line is hung up and the modem is reset and initialized.</LI> |
| + | |||
<LI>Check any Caller-ID information. If <TT>QualifyCID</TT> is configured | <LI>Check any Caller-ID information. If <TT>QualifyCID</TT> is configured | ||
| − | and the caller is not acceptable, then reset and initialize the modem. | + | and the caller is not acceptable, then reset and initialize the modem.</LI> |
| + | |||
<LI>If the call type is already known from distinctive ring information, then | <LI>If the call type is already known from distinctive ring information, then | ||
the call is processed immediately. If faxgetty was instructed to answer | the call is processed immediately. If faxgetty was instructed to answer | ||
| Line 37: | Line 39: | ||
However, if a particular type of call was to be processed (e.g. data) | 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 | and the deduced type of call does not match, then the call is | ||
| − | rejected and the modem is reset and initialized. | + | rejected and the modem is reset and initialized.</LI> |
| + | |||
<LI>If the call type is unknown then the call is answered according | <LI>If the call type is unknown then the call is answered according | ||
to the the current type specified by | to the the current type specified by | ||
| − | <TT>AnswerRotary</TT> and <TT>AnswerRotor</TT>. | + | <TT>AnswerRotary</TT> and <TT>AnswerRotor</TT>.</LI> |
| + | |||
<LI>If the call is not successfully answered and if <TT>AdaptiveAnswer</TT> | <LI>If the call is not successfully answered and if <TT>AdaptiveAnswer</TT> | ||
is enabled, the next item in the <TT>AnswerRotary</TT> list is used | is enabled, the next item in the <TT>AnswerRotary</TT> list is used | ||
to immediately re-answer the call. This is repeated until a call | to immediately re-answer the call. This is repeated until a call | ||
is successfully answered or the list of choices in <TT>AnswerRotary</TT> | is successfully answered or the list of choices in <TT>AnswerRotary</TT> | ||
| + | is exhausted.</LI> | ||
| − | |||
</OL> | </OL> | ||
| + | |||
Call answering is done as follows: | Call answering is done as follows: | ||
| Line 57: | Line 62: | ||
<TT>ModemAnswerVoiceCmd</TT> according to whether the call is to | <TT>ModemAnswerVoiceCmd</TT> according to whether the call is to | ||
be answered as data, fax, or voice, respectively. | be answered as data, fax, or voice, respectively. | ||
| − | If any of these are not set then <TT>ModemAnswerCmd</TT> is used instead. | + | If any of these are not set then <TT>ModemAnswerCmd</TT> is used instead.</LI> |
<LI>Wait for a response from the modem that signifies carrier has | <LI>Wait for a response from the modem that signifies carrier has | ||
been established and which identifies the type of call. | been established and which identifies the type of call. | ||
The exact set of responses is given in | The exact set of responses is given in | ||
| − | <A HREF="man/hylafax-config.html">hylafax-config(4F)</A>. | + | <A HREF="man/hylafax-config.html">hylafax-config(4F)</A>.</LI> |
| + | |||
<LI>If <TT>ModemWaitForConnect</TT> is enabled, then HylaFAX will read | <LI>If <TT>ModemWaitForConnect</TT> is enabled, then HylaFAX will read | ||
responses from the modem until a <TT>CONNECT</TT> response is sent | responses from the modem until a <TT>CONNECT</TT> response is sent | ||
| − | to the host or an error is detected; e.g. | + | to the host or an error is detected; e.g.</LI> |
| + | |||
<UL> | <UL> | ||
| Line 74: | Line 81: | ||
</UL> | </UL> | ||
| + | |||
<LI>If a call is successfully answered, then one of | <LI>If a call is successfully answered, then one of | ||
| Line 82: | Line 90: | ||
This mechanism is useful for modems that automatically change | This mechanism is useful for modems that automatically change | ||
DTE-DCE communication to a fixed line speed or flow control setting | DTE-DCE communication to a fixed line speed or flow control setting | ||
| − | for inbound facsimile calls. | + | for inbound facsimile calls.</LI> |
| + | |||
</OL> | </OL> | ||
| + | |||
At this point the call has been answered, carrier established, | At this point the call has been answered, carrier established, | ||
| Line 90: | Line 100: | ||
<UL> | <UL> | ||
<LI>Data calls are handled by invoking a system getty program; but | <LI>Data calls are handled by invoking a system getty program; but | ||
| − | only if the <TT>GettyArgs</TT> parameter is set. | + | only if the <TT>GettyArgs</TT> parameter is set.</LI> |
<LI>Voice calls are handled by invoking a system vgetty program; but | <LI>Voice calls are handled by invoking a system vgetty program; but | ||
| − | only if the <TT>VGettyArgs</TT> parameter is set. | + | only if the <TT>VGettyArgs</TT> parameter is set.</LI> |
| − | <LI>Facsimile calls are handled directly in faxgetty. | + | |
| + | <LI>Facsimile calls are handled directly in faxgetty.</LI> | ||
</UL> | </UL> | ||
| + | |||
For a data or voice call faxgetty forks and execs the appropriate | For a data or voice call faxgetty forks and execs the appropriate | ||
Revision as of 23:19, 26 October 2006
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.
- 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.
Host Modem
ATA -->
<-- DATA
<-- CONNECT
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.
