Implementing ITU T.30
Wait for Phase D after sending CFR
After sending CFR the receiver should not be quick to fail the session if the Phase C carrier is not detected. The receiver should still wait for the post-page or partial page signal following Phase C. The maximum anticipated wait time for the first signal in Phase D can be estimated relatively well for ECM sessions based on the selected bitrate and knowledge that the maximum size of an ECM block is 64KB. In non-ECM sessions the maximum wait time cannot be accurately anticipated, however, a generous duration of the wait can be modified based on the selected bitrate. Successfully waiting for the post-page or partial page signal permits for the receiver to respond with RTN or PPR and reliably continue the fax session.
Detect premature Phase C carrier loss by looking for RTC signal
Receivers that have successfully trained on the Phase C carrier should deliberately look for the RTC signal in non-ECM sessions or RCP frames in ECM sessions to know if the carrier signal was continuously received to the end of Phase C. Doing this helps identify when an unexpected loss of signal has occurred (due, perhaps, to VoIP jitter). This awareness can help in considerations for the wait duration for the first signal in Phase D (the post-page or partial page signal) and for when a non-ECM page with unlimited page length can be considered prematurely truncated.
Support of CSA/TSA frames is mandatory for DIS/DCS bits 1 and 3
DIS/DCS bits 1 and 3 require that a device handle or ignore TSA/CSA. They should not fail on those signals. Many devices set DIS and DCS bits 1 or 3 but then fail the fax session when a TSA or CSA frame is detected.
Proper RTN handling
Upon detecting an RTN signal from the receiver, the sender must either return to Phase B to retransmit the page - OR - disconnect with DCN. The sender should not return to Phase B only to transmit the next page. That would be appropriate behavior for RTP, not RTN. If the sender cannot retransmit the previous page then it must disconnect. Receivers should be aware that many senders will treat RTN as if it were RTP, and therefore they may want to consider using DCN instead, especially if the Phase C signal was not detected at all and the sender is known to operate incorrectly.
PIN and PIP handling
PIN and PIP signals are not very well supported although T.30 mandates that they be supported. (This is probably because of their possible use as an unlikely operator-involved interruption, although the unattended case was always part of the design.) Firstly, some senders often do not support these signals at all and fail the fax session when they are detected. Even when a sender does not fail the fax session upon detecting PIN/PIP they will usually treat them as if they were RTN/RTP. Thus, the same issue with RTN behavior is present with PIN being treated as if it were PIP (or RTP). PIN and PIP are unique from RTN and RTP in that the former allow the receiver to retransmit DIS whereas the latter do not. Thus, the receiver may potentially modify DIS from what was originally transmitted to compensate for some detected incompatibility with the sender's behavior. Therefore, PIN/PIP should not be treated by senders identically to RTN/RTP.
Proper EOR use
Senders shouldn't use EOR-MPS if they're just going to disconnect after the receiver responds with ERR. In those cases the sender should transmit DCN instead of EOR-MPS. Senders who use EOR-MPS should plan on proceeding to the next page or block after hearing ERR from the receiver. When a sender signals EOR appropriately it should mean that the sender is satisfied with the amount of data that has been indicated as successfully received by the receiver. It should mean that the sender would like to proceed without continuing to retransmit the same data. Likewise, a receiver that responds with ERR should be prepared to continue rather than failing the fax session. If it will refuse to continue the fax session then a receiver should use DCN instead of ERR.
The utility of EOM
A sender may use an EOM or PPS-EOM signal to initiate a document change. However, doing so allows the sender to potentially change their DCS signal, and thus the document format parameters, signaling rate, etc. EOM is a much better-supported way of a sender-initated return to Phase B than is using PRI-Q or PPS-PRI-Q. Because of the possible document format change a receiver is wise to consider EOM as a delimiter between separate documents. Indeed, various fax systems use EOM as a way to send multiple documents in the same fax session. Therefore, senders should certainly use EOM as a delimiter between documents rather than MPS, and senders should limit EOM use to that case as much as possible with the only exception being when it is necessary to change document format parameters within the same document.
Thoughtful use of CTC
CTC can be used by a sender after every fourth PPR signal by a receiver for the same block of data. In the CTC signal the sender is permitted an opportunity to change the bitrate of the communication. However, senders shouldn't slow down the bitrate communication speed if data is getting through at a faster bitrate as doing so has tremendous consequences for communication time of large faxes. While a modulation change can sometimes remedy problems with incompatible modulator/demodulator implementations or specific types of line audio interference, it's also quite likely that slowing down during CTC will only add to the difficulty in getting data through. For example, although a repeating tick or pop in the audio will affect less data at a slower bitrate than it would at a faster bitrate, the slower bitrate also allows less data through in the clear audio between the ticks or pops. The sender can rightly make decision on whether or not a slower bitrate would be useful basd on how much data the receiver is acknowledging as received for each Phase C repetition. However, senders shouldn't make a slower bitrate a matter of habit for every use of CTC. Allowing V.17 to retrain with a session of long-training after a CTC signal can be quite productive.
Phase C carrier training considerations
Modem training can sometimes be a little slower than expected. So, the sender's modem may indicate that the Phase C transmit carrier is raised before the receiver has successfully trained on it. Therefore, senders should add sufficient padding at the beginning of Phase C to avoid the initial data from being missed by the receiver.
Receiver must be prepared for V.21 HDLC instead of Phase C carrier
When listening for the Phase C data a receiver is obliged to listen for both the high-speed data carrier and the slow V.21 HDLC carrier. If the sender did not properly hear the receiver's CFR signal, then the sender will be expected to repeat DCS and TCF. Therefore, the receiver needs to be ready to detect both the Phase C image data and a repeated DCS signal. With class 1 (T.31) modems this will mean that the receiver immediately responds to +FCERROR with the +FRH=3 command. Alternatively, the receiver using a capable T.31 modem could use +FAR=1 to lead the modem to respond +FRH:3 instead of +FCERROR in order to skip the +FRH=3 command.
Deliberately use silence detection and transmisison
Fax protocol is half-duplex, so while one endpoint is signaling the other endpoint should be listening. Modem-based silence detection and transmission commands should be preferred over software-based timers for the sender to ensure that adequate silence follows DCS before TCF and that all other signals do not begin before the other endpoint has stopped signaling. For T.31 modems this means that the +FRS and +FTS commands should be heavily relied upon during fax sessions.
Be prepared to ignore echo
Sometimes poor line conditions lead to considerable echo in the channel. Fax devices should be prepared to ignore this. For every signal sent the device should not fail the fax session just because it hears that same signal back. For example, a receiver who sends MCF should be prepared to ignore hearing an MCF signal immediately afterwards and continue to anticipate the sender's next signal.
Be prepared for out-of-phase signals
It seems that some fax devices tend to view T.30 more as a guideline than as the standard. Therefore, senders should be particularly capable of adapting to out-of-phase signals such as getting Phase B signals such as NSF, CSI, DIS, CFR, and FTT during Phase D. NSF+CSI+DIS or FTT should be treated as if they were an RTN signal (even when ECM is used where RTN/RTP are not allowed). CFR should cause Phase C data to be retransmitted.
No such thing as a zero-frame ECM block
The frame count, block count, and page count bytes in the PPS signal do not provide for an indication of zero. Byte value 0x00 indicates one. Byte value 0xFF indicates 256. Therefore, it is not possible for a sender to indicate that it sent no frames in a Phase C data block as a means to encourage the receiver to respond with MCF. If a sender finds that a receiver transmits a PPR signal that indicates no frames need retransmission then that sender should not transmit an empty Phase C data block with a frame count byte value of 0xFF. Instead, the sender should retransmit the last Phase C data block until an opportunity to signal EOR is reached.
Ignore frame counts in ECM block retransmissions
The receiver must remember the frame count indicated in the first PPS signal for each new block since subsequent PPS signals will only reflect the number of frames in the retransmitted block. The receiver must, then, refer to that first frame count each time it checks to see if it has received all frames of a block.
Utility of CRP
ITU T.30 permits both the sender and the receiver to signal CRP after any set of signals from the other end other than CFR from the receiver. Fax devices should be prepared to repeat their last set of signals (other than CRP, itself) upon detection of CRP from the other endpoint. Detection of CRP following CRP is likely an echo (bit 1 of the FCF indicates which endpoint transmitted the signal) and the device should continue to expect another signal. Senders should not transmit CRP in Phase D, but rather should repeat the post-page or partial page signal - otherwise the receiver would be obliged to re-signal its CFR from Phase B (which is out-of-spec for Phase D) - in which case the sender would be obliged to repeat Phase C.
Requisite retransmisison of signals
Without a response from the remote to indicate that a signal was received properly, all signals must be retransmitted after instead of giving up and failing the fax session immediately. Signals should be repeated at least three times or until the associated timer expires, whichever is more. So, the receiver must repeat NSF/CSI/DIS until it detects TSI/DCS/TCF from the sender. The sender must repeat TSI/DCS/TCF until it detects CFR/FTT from the receiver. The sender must repeat MPS/EOP/EOM/PPS/CTC/EOR until it detects MCF/RTN/RTP/PPR/CTR/ERR from the receiver.
Use DCN when terminating a session
In the event of a decision to terminate the fax session the remote endpoint may appreciate knowing that distinction from another kind of line disconnection issue. Therefore, a fax device should always attempt to transmit DCN rather than just hanging up. This communicates that a decision was made by the device to terminate the call rather than some other kind of problem.
Don't overlook V.29
V.17 has bitrates 14400, 12000, 9600, and 7200 bps. These overlap the V.29 bitrates of 9600 and 7200 bps. However, V.17 9600 bps is not the same as V.29 9600 bps. As the purpose in changing bitrates following RTN, PIN, or in CTC - usually slowing down the communication bitrate - is to change the modulation in hopes of avoiding demodulator incompatibility or some kind of line interference, there is as much or more relevant change between V.17 9600 bps and V.29 9600 bps as there is between V.17 9600 bps and V.17 7200 bps. Therefore, senders should not avoid using V.29 in preference to the same bitrates with V.17. Both modulations should be tried.
Do support ECM
ITU T.30 Annex A, T.4, also known as Error Correction Mode (ECM), is a robust extension of fax communication protocol which enables data to be reliably transmitted by the sender and checked by the receiver, with only portions needing correction to be resent by the sender. Without ECM the receiver is obliged to analyze the data received, estimate the amount of corruption that looks to have occurred during transmission, and weigh that corruption against its own tolerances. Without ECM the sender is obliged to retransmit the entire page of image data or to disconnect whenever the receiver indicates that its tolerances for corruption have been exceeded. Without ECM the receiver must hope that the sender does, actually, retransmit the page of image data upon request without any automatic way to ensure that actually happened rather than the sender entirely skipping the resending of the page. Without ECM the receiver is left to speculate as to how long to wait for the post-page message in the event that it does not properly detect the Phase C data carrier. Without ECM the data format types are limited to data that can generally tolerate some corruption and usually will require significantly more communication time than with data types, such as JBIG, that are supported through use of ECM. So, it is well worth the effort to implement and use ECM.
Avoidance of ECM should be done only rarely
Sometimes fax support persons will recommend that ECM be disabled in order to resolve some kind of communication problem. This is terrible advice. The only reasons that this recommendation would help would be: 1) in very unique circumstances where there is a considerable amount of data corruption but where it will not affect the legibility or use of the document, or 2) in the extremely rare situation where one or both of the endpoints - or a T.38 provider in-between them - have buggy ECM implementations to where ECM cannot function. The typical reason for support persons giving out a recommendation to disable ECM is with an expectation of #1 being the case. However, in practice, #1 is so rarely true that the net effect is for the fax user to simply shift the blame of communication problem from the expected culprit (usually the phone service provider) to the other endpoint or their service provider. Either way, the support persons are rewarded for giving out recommendations to disable ECM to the detriment of a better fax use experience. As for situation #2, this is such a rare situation that it often need not be considered. However, it tends to be most common for users of T.38 services, and the better solution tends to be to disable T.38 rather than disabling ECM.
Usually T.38 avoidance improves reliability
So, that brings us to T.38. Providers of equipment and service for T.38 will laud it as the end-all solution for faxing over VoIP networks. Unfortunately, it isn't. The problem with VoIP networks for fax use is the prevalence of jitter on VoIP networks. Typically the use of ECM can mitigate minor amounts of VoIP jitter. Unfortunately, not all fax endpoints support ECM, which means that fax communications with a remote endpoint that does not support ECM will suffer greatly due to VoIP jitter as Phase C carrier loss and Phase C carrier detection are highly problematic on the receiver when VoIP jitter is present. Then enters all of the issues mentioned previously without ECM support. T.38 has a lot of features, but its primary value for use as a transport on VoIP networks is for use of its optional feature to double, triple, or even quadruple network communication packets to help compensate for jitter due to packet loss. Unfortunately, many T.38 implementations do not use this feature, and worse yet, many T.38 implementations introduce their own set of fax protocol problems such that it is generally better to disable T.38 (so, use G.711), let ECM do its thing as best it can in the face of jitter, and accept the occassional issue for non-ECM fax sessions. Users would be well-served to avoid as much as possible from using VoIP services for fax.
Support SSL Fax
Developers are strongly advised to implement SSL Fax as a means for reliable fax transport on IP networks. It is a much better solution to the problem that T.38 attempts to address.
A note about modem coping efforts countering VoIP jitter
VoIP jitter generally presents itself to a modem as very brief periods of silence. VoIP audio packets are usually 20 ms in length. So, generally VoIP jitter presents itself in the audio stream as null data (zeroes or silence) 20 ms or greater (if multiple sequential packets are affected) in length. If the modem delivers this jitter-based null data to its DSP and if that jitter occurred during a carrier signal the DSP will almost certainly lose proper tracking of that signal. T.30 sometimes uses brief periods of silence as delimiters between signals; however, the shortest length of those delimiters is 75 ± 20 ms (T.30 5.3.2.2), and in practice that delimiter is always 70 ms or more. Therefore, is is possible for the modem to detect and cope with some degree of VoIP jitter by not passing to its DSP periods of null audio data that are roughly between 20 and 60 ms (so, one to three consecutive VoIP audio packets). Doing so prevents minor amounts of VoIP jitter from causing unintended carrier loss. While data within the signal may unavoidably be lost, the DSP is afforded the opportunity to attempt to get as much data from the signal as possible. This is especially useful during Phase C reception.