Re: some faxes not detected, but received on an "old" fax machine

Lee Howard <[email protected]>
Newsgroups gmane.comp.telephony.fax.hylafax.user
Message-ID <[email protected]>
On 08/29/2015 08:57 AM, Laurent Lesage wrote:
> On 27/08/15 16:30, Lee Howard wrote:
>> On 08/27/2015 06:17 AM, Laurent Lesage wrote:
>>> The problem is that some caller can not send faxes. Hera attached, a 
>>> failed transmission.
>> The modem answers the call as instructed, sends NSF/CSI/DIS signals 
>> and then listens for the response from the sender. However, the modem 
>> never hears the response from the sender. And, after a few repeats 
>> HylaFAX gives up.
>>
>> The following are possibilities:
>>
>> 1) The modem really can't hear the response from the sender due to 
>> line audio quality problems.  Maybe the fax machine is able to cope 
>> with the audio quality while the USR modem cannot.
>>
>> 2) Maybe the sender is not in-sync with us properly and somehow that 
>> is tripping-up our ability to detect their signaling. Maybe try 
>> updating HylaFAX to something more-recent than 4.4.4?
> I updated to 6.0.6 without improvement.

I suppose that you could try HylaFAX+ 5.5.6 
(http://hylafax.sourceforge.net) to see if there is any difference, 
there, but I don't know of anything that would be different.

The real complication is that you're using this in your modem config file:

Class1SwitchingCmd:	"<delay\0727>"


... and you may *need* to use that because it's a USR modem. However, 
maybe your particular USR modem is different than those that we've 
tested in the past.  So, maybe you could remove that and get away with 
it.  You'll know that you should use that config setting if you see 
other sessions where the modem seems to "reset" or "restart" itself in 
the middle of fax sessions.  It's pretty obvious if you examine the 
session logs for a day or two.

The use of the AT+FRS command is necessary to sync properly with the 
other end in-case they get out of sync.  If both endpoints don't have 
the "listen for silence" functionality then the likelihood of a 
complication turning into a failure is high.  Unfortunately, our 
experience is that USR modems have trouble with the AT+FRS command 
leading to the modem "resetting" itself.

It may be more straight-forward to just switch modems to something 
that's not USR.  Don't ask me for a recommendation, though.  I have no 
idea what to recommend to people as these days I only ever use Mainpine 
IQ Express modems  and iaxmodems.  Multitechs 5634s have a good 
reputation, and in the past I found them to be reliable, but I haven't 
used one for a long time now.  I especially have limited experience with 
USB modems, which is what you're using.

>>
>> 3) Maybe the sender does not like our NSF/CSI/DIS signals, and so it 
>> disconnects.
>>
> Is there a way to see it and improve this?

If we know what the sender doesn't like about our NSF/CSI/DIS signals 
then we can make adjustments.  We're not doing anything wrong, but we 
can adjust things to accommodate their needs.  For example, old-school 
GammaFax/GammaLink hardware/software does not have the capability to 
change resolution on-the-fly *AND* it does not remember destination 
capabilities, either, and so if a destination does not support fine 
resolution and GammaFax is trying to send a fax with fine resolution, 
then the fax will always fail, and with your setup it could look like 
what you're seeing.  In those cases we "adjusted" things by enabling 
fine resolution support for that sender (even though the receiver's 
administrators did not want to support fine resolution, generally).

That is not what's happening in your case, but it's an example of how we 
may need to adjust things to accommodate the sender.

So, you'd really need to get an idea of what's happening at the sender's 
end.  For example, what kind of error message are they getting?  If it's 
a fax server with logs, can we see the session logs?

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].*
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.