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].*