Re: Unspecified Transmit Phase C Error

Lee,

Thanks so much for that breakdown.

To add another layer on this, the remote device stayed connected for 
64mins (this is a long distance fax) and we have had others that, 
according to the remote site and our phone company, have gone on for 
hours even though we see this as ended.

May 08 13:04:11.47: [ 3625]: Unspecified Transmit Phase C error
May 08 13:04:11.47: [ 3625]: <-- [9:AT+FRS=7\r]
May 08 13:04:11.49: [ 3625]: --> [2:OK]
May 08 13:04:11.49: [ 3625]: <-- [9:AT+FTH=3\r]
May 08 13:04:11.51: [ 3625]: --> [7:CONNECT]
May 08 13:04:11.51: [ 3625]: <-- data [3]
May 08 13:04:11.51: [ 3625]: <-- data [2]
May 08 13:04:12.59: [ 3625]: --> [2:OK]
May 08 13:04:13.59: [ 3625]: <-- [5:ATH0\r]
May 08 13:04:13.71: [ 3625]: --> [2:OK]
May 08 13:04:13.71: [ 3625]: SESSION END

It looks like it hangs up correctly. Is there anything we can do to 
ensure that the line is indeed hung up?

Thanks,

Brian


On 5/9/2018 4:19 PM, Lee Howard wrote:
> On 05/09/2018 08:37 AM, Brian R wrote:
>> I have changed the modemflowcontrol to RTSCTS per other threads with 
>> similar problems.
>
> iaxmodem does not support hardware flow control as the pty interface 
> does not emulate RTS/CTS pins.
>
>> May 08 13:02:06.27: [ 3625]: REMOTE best rate 14400 bit/s
>> May 08 13:02:06.27: [ 3625]: REMOTE max A4 page width (215 mm)
>> May 08 13:02:06.27: [ 3625]: REMOTE max unlimited page length
>> May 08 13:02:06.27: [ 3625]: REMOTE best vres 7.7 line/mm
>> May 08 13:02:06.27: [ 3625]: REMOTE format support: MH
>> May 08 13:02:06.27: [ 3625]: REMOTE best 0 ms/scanline
>
> The receiver does not support error correction mode, unfortunately.
>
>> May 08 13:02:06.27: [ 3625]: USE 9600 bit/s
>> May 08 13:02:06.27: [ 3625]: SEND file "docq/doc.ps;30"
>> May 08 13:02:06.27: [ 3625]: USE A4 page width (215 mm)
>> May 08 13:02:06.27: [ 3625]: USE unlimited page length
>> May 08 13:02:06.27: [ 3625]: USE 3.85 line/mm
>> May 08 13:02:06.27: [ 3625]: USE 1-D MH
>> May 08 13:02:06.27: [ 3625]: USE 0 ms/scanline
>> May 08 13:02:06.27: [ 3625]: SEND training at v.29 9600 bit/s
>
> ... and for some reason you've chosen to not try V.17.
>
>> May 08 13:03:00.33: [ 3625]: SEND send EOP (no more pages or documents)
>> May 08 13:03:00.33: [ 3625]: <-- [9:AT+FTH=3\r]
>> May 08 13:03:00.35: [ 3625]: --> [7:CONNECT]
>> May 08 13:03:00.35: [ 3625]: <-- data [3]
>> May 08 13:03:00.35: [ 3625]: <-- data [2]
>> May 08 13:03:01.43: [ 3625]: --> [2:OK]
>> May 08 13:03:01.43: [ 3625]: <-- [9:AT+FRH=3\r]
>> May 08 13:03:03.07: [ 3625]: --> [7:CONNECT]
>> May 08 13:03:04.11: [ 3625]: --> [2:OK]
>> May 08 13:03:04.11: [ 3625]: SEND recv RTN (retrain negative)
>
> RTN is a complicated signal to interpret.  It only appears when error 
> correction mode is not used.
>
> You're sending a one-page document, and the receiver rejected the page 
> image quality of the first attempt to send the page image data.  For 
> any further pages to be sent a retrain must occur.
>
> The fax specification does not stipulate whether or not the receiver 
> is to expect the sender to retransmit a page following RTN.  The 
> receiver may or may not save or print that page.  All we know is that 
> the receiver rejects the page image quality.  So, if the receiver is 
> not expecting the sender to retransmit pages following RTN then at 
> this point you'd have to hang up and dial again to get a receipt 
> confirmation (MCF).  By default HylaFAX will retransmit pages up to 
> two times more before proceeding with the next page.
>
>> May 08 13:03:04.11: [ 3625]: SEND training at v.29 7200 bit/s
>> ....
>> May 08 13:03:10.97: [ 3625]: TRAINING succeeded
>
> The receiver appears to have tolerated a retraining after RTN.
>
>> May 08 13:03:11.47: [ 3625]: SEND end page
>> May 08 13:04:11.47: [ 3625]: Unspecified Transmit Phase C error
>
> However, after transmitting the page image data the modem does not 
> respond for 60 seconds.  That produces a failure.
>
> There were 55889 bytes in that page, but because you don't have any 
> functional flow control all of those bytes got sent to the modem at 
> once.  At 7200 bps those 55889 bytes will take a minimum of 62 seconds 
> to transmit, so the 60-second modem response "dataTimeout" occurred 
> because the modem was busy transmitting the data still after 60 
> seconds.  So, the failure in this case was due to the lack of flow 
> control and/or a timeout that was too short.
>
> It's still possible that even with flow control that you would have 
> run into the same problem because iaxmodems have a large buffer. (So, 
> flow control may never have even come into play in the first place.)  
> There were fixes in HylaFAX+ 5.5.7 to address the needed increase in 
> the "dataTimeout".
>
> https://sourceforge.net/p/hylafax/HylaFAX+/2370/
> https://sourceforge.net/p/hylafax/HylaFAX+/2364/
> (And the 5 commits in-between were all related, too.)
>
> 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].*