SDK 6.7.3 is the latest Brooktrout development kit providing feature rich capabilities to our partners.  As usual, we’ve added some new features that will be quite useful, and I will discuss a few of them here to give more details on what they do and why they can help you.  Next up to be discussed is a new adaptive fax timer method.

One of the pitfalls with IP fax is incurring delays in the network topology.  Gateways and other IP devices always add delays to the overall end-to-end communication because they need to do their own processing of the media packets.  Most times these delays are negligible, but sometimes they can be just long enough to cause issues with the timing in the fax protocol.  When a fax device sends a command out, like an MPS message at the end of a fax page, it waits for a certain amount of time to get a response back.  This time is called the T4 fax timer and it's usually about 4-5 seconds.  If no response comes back in that time, the end point sends the command again, up to three times before giving up.  With delays, the response may come back too late so that the sending side is already repeating its message again.  Fax is half-duplex, meaning a side can send or listen but not both at the same time.  So if the sender is transmitting its command again, it won't hear if the response comes late and the two sides never sync up.

The Brooktrout API does already provide a means to increase the T4 timer on the SR140.  There is a parameter in btcall.cfg called t4_xmit_timer that statically sets that value. But what if you only have some calls with delay issues because the delays are being caused by something on the far end side, not your own?  Maybe you'd want to increase the T4 timer only for those calls or only when after trying to send one round of commands. 

The new feature in SDK 6.7.3 allows the SR140 application to control the T4 timer as it sees fit.  A new API function called BfvFaxT4TimerParams allows an application to set up a callback function, and in that callback function the application will have access to some information about the T4 timer.  Specifically, the application can be told four things: the current setting of the T4 timer, the amount of time a response took to arrive (if it did arrive), on which attempt to send the command this was for (for example sending the first MPS, the second MPS, etc.), and a flag to indicate if there was a timeout.  Based on this information, the application can also set the T4 timer for the next try.

To use this feature, you also need to set a parameter in btcall.cfg called “t4_timer_mode” to 2.  This enables the SR140’s firmware to generate the T4 timer information for the application’s callback to examine. 

Below is a debug log snippet after sending a fax EOP command (End of Procedures) indicating the end of the last page and receiving an MCF response (Message Confirmation) back.  The SR140’s firmware provides the information about the T4 timer.  In this case, since the response was received back (i.e. no T4 timeout), the Timeout flag is 0.


06/19 16:41:43.85 57[41,3] > ff 13 2f 00 00
06/19 16:41:43.85 57[41,3]   EOP End of procedures
06/19 16:41:45.16 57[41,3] < (09) FAX (08) EVENT (12) T4_ADAPT_INFO
    (AC) T4_TIMER_ADAPT_CURRENT [42: Fix Uns Long MSec] 00001400
    (AD) T4_TIMER_ADAPT_DURATION [42: Fix Uns Long MSec] 0000009C
    (AE) T4_TIMER_ADAPT_ATTEMPT [02: Fix Uns Long Unitless] 00000000
    (AF) T4_TIMER_ADAPT_TIMEOUT [02: Fix Uns Long Unitless] 00000000

Current T4 timer value = 5120
Duration to receive the last response = 156
Attempt number for command/response exchange = 0
Timeout flag = 0

06/19 16:41:46.03 57[41,3] < (09) FAX (08) EVENT (05) FSK_DATA
    (0E) FSK_DIR [00: Fix Uns Byte Unitless] 01
    (0F) FSK_DATA [00: Fix Uns Byte Unitless] FF 13 8C 00 00
06/19 16:41:46.03 57[41,3] < ff 13 8c 00 00 06/19 16:41:46.03 57[41,3]   MCF Message Confirmation