Re: How important are AT+FRS and AT+FTS?

On 12/22/2017 12:23 PM, Christo Labuschagne wrote:
> So, today, after very long hours of debugging, we noticed that FRS and FTS on our modem does not react as it should. They just return OK immediately.

What type of modem is this?

> This has been confirmed by the manufacturer...  so on a scale of 1 to 10, in how much trouble are we?

It depends on your needs and goals.  If your goal is to have the 
most-reliable fax operations as possible then not being able to detect 
silence is going to make that impossible.  If your goal is to be able to 
send and receive a few faxes once in a while, then not being able to 
detect silence may not be a show-stopper.

>  From what I understand from the code, these are used to try and sync.

Yes.  Non-SuperG3 fax is a half-duplex communication, and so it's 
important to make sure that we don't send signals while the other end is 
also sending signals.  Also, it's important to make sure that the 
timings between our signals are correct.  The fax specification (ITU 
T.30) has numerous instances where there are mandatory timings.  The 
+FRS and +FTS commands help us get there.

> One of the bugs where we noticed this was when we receive ERROR right after the first CONNECT during V17 transfer on the call initiator.  Basically NSF corrupts, and we then just bash out CRP while CSI and DSI are still coming in. CRP should only go out after DSI according to spec, but it seems like HylaFax just issue AT+FRS=x*3 before sending CRP. Any tips?

The fax receiver will transmit NSF, CSI, and DIS at the outset of a 
call.  If the call audio quality is poor or disrupted (such as with a 
sloppy SIP media transition from G.711 to T.38) then one or more of 
those signals can be corrupted.  This will lead to an ERROR result in an 
+FRH=3 (or ATA) command.  There are multiple ways in which this could be 
handled but primarily there are two:

1) We can remain silent and wait for the receiver to retransmit NSF, 
CSI, and DIS until we get them properly.

2) We can issue CRP to prompt the receiver to retransmit NSF, CSI, and DIS.

The problem with #1 is that the receiver may never retransmit NSF, CSI, 
and DIS without being prompted to.  This is technically a bug in the 
receiver, but unfortunately it's not terribly uncommon.  This is what 
you're encountering.  You're sending CRP while the receiver is still 
transmitting CSI and DIS, and so they're not hearing it which leads to 
problems.  The difficulty with #2 is that it really requires that the 
modem have the ability to detect silence - to know when the receiver is 
listening.

It is possible that the receiver is being tripped-up by the untimely CRP 
- that it finishes DIS and notices a broken signal from the sender, 
incorrectly and unwisely assumes that it was TSI, DCS, and TCF, and 
therefore abandons the otherwise required retransmits of NSF, CSI, and 
DIS - since it would be expecting the sender to retransmit TSI, DCS, and 
TCF.  If this is the case, then the fix would be to do #1 in cases where 
the modem does not support +FRS properly.  However, HylaFAX doesn't 
currently do that... it could, but it doesn't yet.  (And, honestly, it 
may not really help because this was all speculative, anyway.)

> On an unrelated topic. We use HylaFax between two devices but they will not send data on high speed. We can see that the exchange does not happen over T.38 because the NSF data is still correct. We tried to send in both directions about 5 times. We then hooked up a Bother fax machine on the receiving side, sent a fax successfully. We subsequently reconnected the previously non-working system and everything kept on working. Does anyone have any experience on when or under what circumstances a service provider would engage the T.38 protocol? It seems like some black magic going on on the backend. Is it because of the calling tone, or the answering tone, the delay until NSF?

I think that you'd need to share the session log(s) with us of those 
failed sessions for us to comment on what may have been happening there.

However... if you are using VoIP channels for your fax line... simply 
the various factors involving call audio quality in a VoIP call do vary 
over time.  So, you may send 5 faxes to have them all fail only to then 
send another 30 faxes without failure.  Eventually you'll run into 
another bunch of failures, etc.

Thanks,

Lee.


____________________ HylaFAX(tm) Users Mailing List _______________________
  To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi
 On UNIX: mail -s unsubscribe [email protected] < /dev/null
  *To learn about commercial HylaFAX(tm) support, mail [email protected].*