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