Re: Failure To Train Modem Speed
Brian <[email protected]> Fri, 17 Feb 2017 06:31:22 -0500
| Newsgroups | gmane.comp.telephony.fax.hylafax.user |
|---|---|
| Message-ID | <[email protected]> |
On 2/17/2017 12:52 AM, Lee Howard wrote: > On 02/16/2017 06:26 PM, Brian wrote: >> Anyone? >> >> >> On 2/10/2017 2:41 PM, Brian wrote: >>> Good Day, >>> >>> I was hoping someone could help me out with this issue. >>> >>> We have a Hylafax-IAXmodem-Asterisk system with a Digium Inc >>> Wildcard TE121. It works very well, however we have one partner that >>> we are unable to fax to. That site is using CX93010 Conexant USB >>> dongle on a Windows server. They report no problems with any other >>> partners. >>> >>> The notification email says "Problem sending the fax.: Failure to >>> train remote modem at 2400 bps or minimum speed; Giving up after 3 >>> attempts to send same page" >>> >>> This is what we see in the log: >>> >>> Feb 10 13:51:55.89: [29624]: SESSION BEGIN 000306517 1234567890 >>> Feb 10 13:51:55.89: [29624]: HylaFAX (tm) Version 6.0.3 >>> Feb 10 13:51:55.89: [29624]: SEND FAX: JOB 2089439 DEST 1234567 >>> COMMID 000306517 DEVICE '/dev/ttyIAX05' FROM 'XYZ' USER fax >>> Feb 10 13:51:55.89: [29624]: <-- [14:AT+FCLASS=1.0\r] >>> Feb 10 13:51:55.91: [29624]: --> [2:OK] >>> Feb 10 13:51:55.91: [29624]: DIAL 6243423 >>> Feb 10 13:51:55.91: [29624]: <-- [12:ATDT1234567\r] >>> Feb 10 13:52:14.85: [29624]: --> [7:CONNECT] >>> Feb 10 13:52:16.27: [29624]: --> [2:OK] >>> Feb 10 13:52:16.27: [29624]: REMOTE CSI "Fax" >>> Feb 10 13:52:16.27: [29624]: <-- [9:AT+FRH=3\r] >>> Feb 10 13:52:16.59: [29624]: --> [7:CONNECT] >>> Feb 10 13:52:16.69: [29624]: --> [2:OK] >>> Feb 10 13:52:16.69: [29624]: REMOTE best rate 14400 bit/s >>> Feb 10 13:52:16.69: [29624]: REMOTE max A4 page width (215 mm) >>> Feb 10 13:52:16.69: [29624]: REMOTE max unlimited page length >>> Feb 10 13:52:16.69: [29624]: REMOTE best vres 7.7 line/mm >>> Feb 10 13:52:16.69: [29624]: REMOTE format support: MH, MR >>> Feb 10 13:52:16.69: [29624]: REMOTE best 0 ms/scanline >>> ..... >>> Feb 10 13:52:55.64: [29624]: <-- [10:AT+FTM=24\r] >>> Feb 10 13:52:55.66: [29624]: --> [7:CONNECT] >>> Feb 10 13:52:55.66: [29624]: DELAY 400 ms >>> Feb 10 13:52:56.06: [29624]: <-- data [450] >>> Feb 10 13:52:56.06: [29624]: <-- data [2] >>> Feb 10 13:52:58.18: [29624]: --> [2:OK] >>> Feb 10 13:52:58.18: [29624]: <-- [9:AT+FRH=3\r] >>> Feb 10 13:52:58.72: [29624]: --> [7:CONNECT] >>> Feb 10 13:52:59.72: [29624]: --> [2:OK] >>> Feb 10 13:52:59.72: [29624]: TRAINING failed > > Unfortunately, there's not much that can be said beyond what the > failure message is saying. > > The remote system didn't signal NSF and doesn't support ECM, so it's > probably safe to say that the receiver is just a simple fax software > application. Consequently, it sometimes is difficult to get things > through on them because they may not be doing things as they should. > They may report no other problems with other partners, but that's > certainly incorrect. The mere fact that ECM is not supported can > guarantee that they do have other problems - at least sometimes. > > The log shows that the receiver stays connected the entire time, so > it's not hanging up even though it seems to not be responding every > time it is expected to respond. That's good. However, it's signaling > FTT (failure to train) at every time we see any response to our > DCS+TCF. We don't know *why* the receiver is signaling FTT. That's > something that the logs on the receiver's end would have to say. > > However, if the receiver software is developed at least somewhat > rationally then FTT would either indicate that the TCF signal is not > getting through clearly or that the TCF signal is not being received > in its entirety. Normally that would be line audio quality issues. > But, as you say, you're not having problems sending faxes elsewhere. > > So, really, unless you can get some better diagnostics from the > receiver the only thing that you can do would be to try various > different fax delivery methods until you found one that worked... and > then work-out from there the differences and what made that method > work but not the one you're currently using. > > For example, it's remotely possible that something in HylaFAX+ 5.5.8 > would make a difference - but admittedly that is unlikely. If the > receiver would tolerate a test fax, I would be happy to send a test > fax there using my equipment that is similar to yours. > > Thanks, > > Lee. > > Lee, Thanks for taking the time to reply, it is appreciated. Brian ____________________ 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].*