Differences in HylaFAX+ compared to HylaFAX found at hylafax.org

HylaFAX+ includes fixes and features not found in the HylaFAX at hylafax.org. There are various bugfixes and other improvements including improved fax protocol, modem support, and support of some specific modem behaviors. The entire list of changes would be too long to be meaningful to most readers, and such a list is no longer actively maintained, but here is a smaller list of noteworthy differences.

1. simplified default faxrcvd, notify, and pollrcvd for easier customization

Instead of following hylafax.org's path into mail templates as a solution for mail customization and translations, HylaFAX+ stays with the traditional approach for mail customization - customization of the faxrcvd, notify, and pollrcvd mailing shell scripts - and stays with the relatively recent "dictionary" approach for translations. However, these three mailing shell scripts have been simplified in their scripting to make them more readable and easier to customize.

Templating does not necessarily make mail customization any easier. Take for instance the administration of a HylaFAX server that services users of multiple languages. In the minimal-alteration case where mere wordings are being changed, with the traditional approaches the administrator would add a case statement to etc/FaxDictionary and within it set some DICT variables to modify the wordings found in bin/dictionary. With the template approach the administrator would be required to modify wordings in numerous mail templates for each language. In the full-customization case where customized mail content is dynamic and where mail wordings and formatting are being entirely rewritten, with the traditional approaches the mailing scripts are customized, and now the scripts have been simplified to allow that customization to occur within one single mailing function in each script. With the template approach the administrator would be required to learn and probably modify the templating functions within the mailing scripts themselves as well as then recreate all of the numerous template files for each language.

Templating does not make a translator's job any easier. With the "dictionary" approach the translator is merely required to translate a bunch of phrases or words in the bin/dictionary script. With the template approach the translator not only is required to translate but to also then duplicate that work numerous times.

Indeed, it is difficult to imagine a case where the templating approach actually makes customization or translation any easier for the administrator. The only conceivable benefit would be in cases where the administrator needs to make only the most simple alterations and would be prone to cause the mailing scripts to error-out in attempts to modify them without an ability to debug them afterwards.

See the HOWTO's Localization and Customization of E-mails for more a more detailed description of just how easy the HylaFAX+ method of mail customizations really is.

2. extended presentation of CallID

CallIDLabel, CallIDDisplay, and CallIDRecord can be used together to present CallIDPattern match data in the modem status string and faxinfo output. So, for example, with these entries in a modem configuration file: 

  CallIDPattern:        "NDID="
  CallIDLabel:		"DID"
  CallIDDisplay:	yes
  CallIDPattern:        "NMBR="
  CallIDLabel:		"CID"
  CallIDDisplay:	yes
  CallIDRecord:		no
  CallIDPattern:	"NAME="
  CallIDLabel:		"CID"
The faxstat output could look like this: 

  Modem ttyIAX0 (+1.999.888.0000): Running and idle
  Modem ttyIAX1 (+1.999.888.0000): Answering the phone, DID:1000, CID:7776665432
  Modem ttyIAX2 (+1.999.888.0000): Receiving facsimile, DID:1001, CID:7776664321
  Modem ttyIAX3 (+1.999.888.0000): Receiving from "+1.777.666.3210", DID:1002, CID:7776663210
And the faxinfo output could look like this: 

      Sender: +1.777.666.3210
       Pages: 2
     Quality: Normal
        Page: North American Letter
    Received: 2006:10:29 09:00:40
  TimeToRecv: 0:17
  SignalRate: 9600 bit/s
  DataFormat: JBIG
  ErrCorrect: Yes
         DID: 1002
         CID: Lee Howard
Notice in this last case that "DID" and "CID" are used instaead of CALLID1 and CALLID2, making the information there more meaningful for those using raw faxinfo output and not requiring any translation of those in etc/FaxDictionary for meaningful presentation in the default faxrcvd notification mail.

Of course, the default behaviors for all of these options is for traditional output in both situations.

3. ModemSetOriginCmd, ModemDialCmd, FAXNAME job parameter, and -e "name" and -u "number" sendfax options

The ModemSetOriginCmd allows the administrator to set the outbound Caller*ID values for various modems that support setting the call origination information (for example IAXmodem and Eicon Diva Server). The new FAXNAME job parameter in conjunction with the FAXNUMBER job parameter allow the various client programs to specify these call origination values, and are then used if the administrator configures it. The sendfax client uses the 'sendfax -e "name"' and 'sendfax -u "number"' options for this purpose.

For example, on the Eicon Diva Server this configuration item will cause the modem to be initialized with the appropriate origination information provided by the administrator or user in the "FANUMBER" job parameter: 


  ModemSetOriginCmd:    AT+iO%d
On an IAXmodem this configuration item will cause the modem to be initialized similarly with information provided in the "FAXNUMBER" and "FAXNAME" job parameters: 

  ModemSetOriginCmd:    AT+VSID="%s","%d"
Similarly HylaFAX+ includes an extension to the ModemDialCmd feature that allows it to utilize a similar capacity in t38modem except that it is done in the dial command like this: 

  ModemDialCmd:         ATDT%sL%d
On a t38modem this configuration item will cause the dial command to include the calling number (where %d appears) provided to the server from the job information.

4. faxmail comes with default MIMEDecoders for PDF and TIFF attachments

Externally formatted attachments in faxmail are now no longer require the various "showpage" and trailer workarounds for the usual functionality. Plus, default MIMEDecoders for PDF and TIFF attachments are installed - meaning faxmail now supports TIFF and PDF attachments by default.

5. etc/FaxAccounting reliable event hook, particularly for adding xferfaxlog data to a database

If an executable file named ``etc/FaxAccounting'' exists in the HylaFAX spool directory then it will be executed every time a record is written to etc/xferfaxlog. The record fields will each serve as separate command arguments. This is designed to allow attachment to external databases and other accounting mechanisms. However, it also provides a reliable event hook for other purposes (unlike ``etc/FaxNotify'' which is only triggered if the user requested notification, for example).

6. xferfaxlog extensions (SUBMIT records and jobinfo field)

The information written to xferfaxlog (and thus also FaxAccounting) has been extended. Specifically there are now "SUBMIT" records that are written for each job submission, and there is a new "jobinfo" field that contains various pieces of information concerning job progression (totpages, ntries, ndials, totdials, maxdials, tottries, and maxtries).

7. BadPageHandlingMethod feature defaulting with RTN-SAVE

If a page is received in non-ECM mode with unacceptable quality according to PercentGoodLines or MaxConseutiveBadLines then it can be somewhat difficult to inform the sender of the problem. Historically, HylaFAX has assumed that signalling RTN to the sender will accomplish this. However, some senders are incapable of retransmitting pages, and to reduce burden they treat an RTN signal as a receipt confirmation and proceed to the next page without notifying the sending user of the potential problem in readability on the receive-end. (The assumption there being that the receiving user will notify the sending user if there actually is a redability problem.)

The BadPageHandlingMethod is available to allow the administrator to cope with the uncertainty in sender behavior.

A setting of ``RTN'' is the historic behavior and assumes that an RTN signal will be enough to get the sender to retransmit or be otherwise informed of a potential readability problem on the receive-end. The previously-received page data is marked to be overwritten by the next page data received from the sender.

A setting of ``DCN'' tells HylaFAX to transmit a DCN signal in response to the post-page message and should trigger a call abortion by the sender. This should clearly indicate a problem in page readability to the sender, although the receipt of any following pages in a later call cannot be guaranteed.

A setting of ``RTN-SAVE'' more closely approximates the behavior of other fax receivers (especially fax machines). It causes HylaFAX to send the RTN signal but it saves the previously received page data and places the next transmitted page data in another page. This is the default setting. However, this could result in multiple copies of the same page image being saved in the same file - if the sender does indeed retransmit the unacceptable pages during the same call.

8. More feature support (i.e. JBIG, JPEG) in the Class 2/2.0/2.1 driver.

With a Class 2/2.0/2.1 modem that supports these features, HylaFAX+ also supports JBIG compression (both sending and receiving) and JPEG (color fax, receive-only). Also supported are the capabilities to disable V.34 or V.17 on-the-fly when so-desired.

9. StaggerCalls feature for faxq

Some users have expressed a potential problem that occurs when a HylaFAX server has a small number of lines that are shared as both sending and receiving. If a large outbound send queue occurs then it can effectively cause the lines to be continually busy and impairs the receiving service. StaggerCalls permits the administrator to limit the frequency of the scheduler initiating an outbound call, and thus hopefully making the line available for some time to receive incoming faxes.

10. place non-ready ModemReadyState onto modem status string and add "exempt" option

The purpose in the ModemReadyState modem config option is to allow the administrator the ability to remove a modem from servicing outbound jobs even though it may initialize properly. An administrator may do this, for example, to temporarily use the line for another purpose, to indicate that the line is somewhat more permanently unavailable, or to indicate that the modem is configured for receive-only use. HylaFAX+ displays this state into the modem status string so that users and administrators can readily recognize it. HylaFAX+ also adds the "exempt" state which indicates that the modem is configured for receive-only use instead of it being temporarily busy or more permanently unavailable. 

  Modem ttyIAX0 (+1.999.888.0000): Running and idle (exempt)

11. "play" escape option for modem configuration to use voice playback features

Some administrators with supporting voice modems have expressed the desire to play a brief voice message (like, "Start your fax now") to the caller before answering the call with fax answering tones. HylaFAX+ includes a "play" escape option for modem configuration to use voice playback features for this purpose. For example, a configuration of... 

  ModemRingResponse:  "AT+FCLASS=8;H1\nAT+VSM=131\nAT+VLS=1\nAT+VTX\nAT+VTS=[933,,150]"
  ModemAnswerCmd:     "AT+FCLASS=1;A"
  CallIDPattern:      SHIELDED_DTMF
  CallIDAnswerLength: 4
In this example using an IS-101 voice-compliant modem, a RING indication from the modem will cause the modem to be placed in voice mode, set ulaw audio compression, and via the connected phone line play back the etc/play1.raw audio file, which may say, "After the tone enter a four-digit extension, then start the fax." Following the message a tone is played.

12. Class1PageLengthSupport modem config option

The Class1PageLengthSupport found in HylaFAX+ allows the administrator to configure the page-length support for Class 1 modems. An administrator may use this feature to, for example, prohibit the reception of anything except A4-sized or US letter-sized pages.

13. -nointeractive option for faxsetup and faxaddmodem (like configure)

Some people have expressed a desire to script an installation or configuration of HylaFAX that does not involve user interaction. The -nointeractive option for faxsetup and faxaddmodem in HylaFAX+ operates like it does with the configure script and allows the scripts to run without user interaction.

14. no JobControlWait option

JobControl was a replacement for DestControls. Previously with DestControls the operations involving it would be sure to complete before execution would continue. Usually this did not cause much delay because DestControls were rather simple without any real method of causing a severe delay. However, with the added amount of control that JobControl gives to the administrator, there is also an increased risk that JobControl has in permitting the administrator to slow down the performance of faxq due to processing time in JobControl. This risk is mitigated by the code at hylafax.org through the JobControlWait feature. By disabling JobControlWait the administrator can permit fax processing to continue without blocking until JobControl finishes. HylaFAX+ does not have this feature for some important reasons.

* The chances of JobControl blocking for an amount of time that is at all noticeable is rather slim. And even in the remote chance that the administrator configured a JobControl that would block for a noticeably long time, the chances of that performance hit being a problem are also rather slim. Put those two remote possibilities together and you get something that's really never going to happen in normal, everyday scenarios.

* JobControlWait interferes with batching. Without the block and when using JobControl, it is relatively impossible to guarantee that any jobs will batch properly. And, in fact even an imperceptible delay in processing in JobControl will keep two jobs from batching. In the past HylaFAX users have been very concerned about guaranteeing job batching. Users have never expressed worry about faxq performace difference of the kind that JobControl could normally create.

* Disabling the block on JobControl makes it impossible to someday extend the JobControl RejectNotice to reject job submissions (or otherwise involve JobControl) in the client-server protocol (hfaxd communication).

* To characterize the disabling of JobControlWait as a means to achieve "maximum faxq performance" is only likely to mislead the administrator into doing exactly that.