Re: Can't send Fax but can Receive

Today I discoverd that with a Real FAX Machine connected into a sip
extension I can send faxes.

I believe that this is due to the fact this machine supports t38 and the
virtual fax with IAX modem doesn't.

Is there any way to use a virtual fax with a t38modem.

I know that there is a t38modem but it's really hard to compile on centOS.
Any suggestion?

Thanks!!

2017-10-12 20:28 GMT+01:00 FM <[email protected]>:

> In fact, it did not help...
>
> It seems I have to call the ISP again :\
>
> Oct 12 20:25:50.53: [ 2393]: SESSION BEGIN 000000027 00351222138xxxxx
> Oct 12 20:25:50.53: [ 2393]: HylaFAX (tm) Version 4.3.11
> Oct 12 20:25:50.53: [ 2393]: SEND FAX: JOB 15 DEST 2138xxxxx COMMID
> 000000027 DEVICE '/dev/ttyIAX1' FROM 'Asterisk VoIP PBX <asterisk@localhost>'
> USER asterisk
> Oct 12 20:25:50.53: [ 2393]: STATE CHANGE: RUNNING -> SENDING
> Oct 12 20:25:50.53: [ 2393]: <-- [12:AT+FCLASS=1\r]
> Oct 12 20:25:50.53: [ 2393]: --> [2:OK]
> Oct 12 20:25:50.53: [ 2393]: MODEM set XON/XOFF/FLUSH: input ignored,
> output disabled
> Oct 12 20:25:50.53: [ 2393]: DIAL 2138xxxxx
> Oct 12 20:25:50.53: [ 2393]: <-- [14:ATDT2138xxxxx\r]
> Oct 12 20:25:56.41: [ 2393]: --> [7:CONNECT]
> Oct 12 20:26:01.69: [ 2393]: --> [4:CE 00 10 03]
> Oct 12 20:26:01.69: [ 2393]: --> [5:ERROR]
> Oct 12 20:26:01.69: [ 2393]: MODEM Command error
> Oct 12 20:26:01.69: [ 2393]: FCS error
> Oct 12 20:26:01.69: [ 2393]: <-- [9:AT+FRS=7\r]
> Oct 12 20:26:02.57: [ 2393]: --> [2:OK]
> Oct 12 20:26:02.57: [ 2393]: <-- [9:AT+FTH=3\r]
> Oct 12 20:26:02.59: [ 2393]: --> [7:CONNECT]
> Oct 12 20:26:02.59: [ 2393]: <-- HDLC<3:FF C8 D8>
> Oct 12 20:26:02.59: [ 2393]: <-- data [3]
> Oct 12 20:26:02.59: [ 2393]: <-- data [2]
> Oct 12 20:26:03.69: [ 2393]: --> [2:OK]
> Oct 12 20:26:03.69: [ 2393]: SEND send CRP (command repeat)
> Oct 12 20:26:03.69: [ 2393]: <-- [9:AT+FRH=3\r]
> Oct 12 20:26:04.26: [ 2393]: --> [7:CONNECT]
> Oct 12 20:26:05.41: [ 2393]: --> HDLC<15:FF C8 01 00 77 0F 01 01 C9 01 01
> 01 18 32 36>
> Oct 12 20:26:05.43: [ 2393]: --> [2:OK]
> Oct 12 20:26:05.43: [ 2393]: REMOTE best rate 14400 bit/s
> Oct 12 20:26:05.43: [ 2393]: REMOTE max A4 page width (215 mm)
> Oct 12 20:26:05.43: [ 2393]: REMOTE max A4 page length (297 mm)
> Oct 12 20:26:05.43: [ 2393]: REMOTE best vres 300 x 300 dpi
> Oct 12 20:26:05.43: [ 2393]: REMOTE format support: MH, MR
> Oct 12 20:26:05.43: [ 2393]: REMOTE best 0 ms/scanline
> Oct 12 20:26:05.43: [ 2393]: USE 9600 bit/s
> Oct 12 20:26:05.43: [ 2393]: SEND file "docq/doc15.ps;41"
> Oct 12 20:26:05.43: [ 2393]: USE A4 page width (215 mm)
> Oct 12 20:26:05.43: [ 2393]: USE A4 page length (297 mm)
> Oct 12 20:26:05.43: [ 2393]: USE 7.7 line/mm
> Oct 12 20:26:05.43: [ 2393]: USE 2-D MR
> Oct 12 20:26:05.43: [ 2393]: USE 0 ms/scanline
> Oct 12 20:26:05.43: [ 2393]: SEND training at v.29 9600 bit/s
> Oct 12 20:26:05.43: [ 2393]: <-- [9:AT+FRS=7\r]
> Oct 12 20:26:05.53: [ 2393]: --> [2:OK]
> Oct 12 20:26:05.53: [ 2393]: <-- [9:AT+FTH=3\r]
> Oct 12 20:26:05.55: [ 2393]: --> [7:CONNECT]
> Oct 12 20:26:05.55: [ 2393]: <-- HDLC<23:FF C0 C2 04 04 04 04 04 04 04 04
> 04 04 04 04 04 04 04 04 04 04 04 04>
> Oct 12 20:26:05.55: [ 2393]: <-- data [23]
> Oct 12 20:26:05.55: [ 2393]: <-- data [2]
> Oct 12 20:26:07.12: [ 2393]: --> [7:CONNECT]
> Oct 12 20:26:07.12: [ 2393]: <-- HDLC<6:FF C8 C1 00 63 0E>
> Oct 12 20:26:07.12: [ 2393]: <-- data [6]
> Oct 12 20:26:07.12: [ 2393]: <-- data [2]
> Oct 12 20:26:07.49: [ 2393]: --> [2:OK]
> Oct 12 20:26:07.49: [ 2393]: <-- [9:AT+FTS=7\r]
> Oct 12 20:26:07.59: [ 2393]: --> [2:OK]
> Oct 12 20:26:07.59: [ 2393]: MODEM set XON/XOFF/FLUSH: input interpreted,
> output disabled
> Oct 12 20:26:07.59: [ 2393]: <-- [10:AT+FTM=96\r]
> Oct 12 20:26:07.61: [ 2393]: --> [7:CONNECT]
> Oct 12 20:26:07.61: [ 2393]: DELAY 400 ms
> Oct 12 20:26:08.01: [ 2393]: <-- data [1024]
> Oct 12 20:26:08.01: [ 2393]: <-- data [776]
> Oct 12 20:26:08.01: [ 2393]: <-- data [2]
> Oct 12 20:26:09.59: [ 2393]: --> [2:OK]
> Oct 12 20:26:09.59: [ 2393]: MODEM set XON/XOFF/DRAIN: input ignored,
> output disabled
> Oct 12 20:26:09.59: [ 2393]: <-- [9:AT+FRH=3\r]
> Oct 12 20:26:10.12: [ 2393]: --> [7:CONNECT]
> Oct 12 20:26:11.02: [ 2393]: --> HDLC<5:FF C8 5F C8 E7>
> Oct 12 20:26:11.04: [ 2393]: --> [2:OK]
> Oct 12 20:26:11.04: [ 2393]: TRAINING failed
> Oct 12 20:26:11.04: [ 2393]: <-- [9:AT+FTH=3\r]
> Oct 12 20:26:11.06: [ 2393]: --> [7:CONNECT]
> Oct 12 20:26:11.06: [ 2393]: <-- HDLC<3:FF C8 DF>
> Oct 12 20:26:11.06: [ 2393]: <-- data [3]
> Oct 12 20:26:11.06: [ 2393]: <-- data [2]
> Oct 12 20:26:12.16: [ 2393]: --> [2:OK]
> Oct 12 20:26:12.16: [ 2393]: MODEM input buffering enabled
> Oct 12 20:26:12.16: [ 2393]: <-- [5:ATH0\r]
> Oct 12 20:26:12.28: [ 2393]: --> [2:OK]
> Oct 12 20:26:12.28: [ 2393]: MODEM set DTR OFF
> Oct 12 20:26:12.28: [ 2393]: MODEM set baud rate: 0 baud (flow control
> unchanged)
> Oct 12 20:26:12.28: [ 2393]: STATE CHANGE: SENDING -> MODEMWAIT (timeout 5)
> Oct 12 20:26:12.28: [ 2393]: SESSION END
>
>
> 2017-10-12 18:36 GMT+01:00 Lee Howard <[email protected]>:
>
>> It won't help.
>>
>> They say that because Hewlett Packard in the mid 1990's made that
>> suggestion in one of their fax machine tech support guides.
>>
>> HP made that suggestion to 1) avoid potentially buggy ECM
>> implementations, 2) shake up the modulation which can help on PSTN noise
>> conditions, and 3) to just get customers to go away since it increases the
>> likelihood that the fax machine will shoot out some paper print of some
>> kind even if it's not perfectly legible.
>>
>> VoIP providers have latched onto that advice because of #3. #1 is not
>> relevant any more because buggy ECM implementations are not widely in-use,
>> and #2 is not relevant to VoIP.
>>
>> So, it sometimes really did help at one time in the past, but in today's
>> world it's extremely unlikely to be of much help.  Fax machines
>> automatically cycle through various modulations in trying to get the fax
>> through.  So, for the most part you can respond back to your ISP that their
>> recommendation to set the fax to 9600 bps is done on-the-fly automatically.
>>
>> As for ECM being disabled, there are various ways to do it.  All that
>> doing it will achieve will be to let some more faxes through with
>> horizontal black/white lines and corrupted/illegible text and images.  If
>> you're using a Class 1 modem then in your modem config file you'd put:
>>
>> Class1ECMSupport: false
>>
>> To limit faxes to 9600 bps you'd use:
>>
>> Class1RMQueryCmd:    "!24,48,72,96"
>> Class1TMQueryCmd:      "!24,48,72,96"
>>
>> Thanks,
>>
>> Lee.
>>
>>
>>
>> On 10/10/2017 11:06 AM, FM wrote:
>>
>> Hi!
>>
>> The ISP told me to set the fax to 9600bps and disable ECM.
>>
>> How can I achieve this with hylafax?
>>
>> Thank you!!
>>
>> 2017-10-05 17:42 GMT+01:00 Lee Howard <[email protected]>:
>>
>>> On 10/05/2017 05:25 AM, FM wrote:
>>>
>>>> My ISP is at the same time My VOIP provider. I use a sip trunk for
>>>> voice + fax. I use ullaw and allaw as codecs.
>>>>
>>>> The strange thing is, some months ago I was able to send fax with no
>>>> problem.
>>>>
>>>
>>> That is not strange at all.  VoIP jitter is a variable depending on so
>>> many things.  So, that it was better before and is worse now is not unusual
>>> for VoIP.  Chances are that in a week or two or a day or two it will be
>>> even worse or better.
>>>
>>> By the way, if I send fax to a number that also is a virtual fax with
>>>> hylafax + iax2 extension it Never fails.
>>>>
>>>
>>> So, that tells you that the call audio quality on that call path is
>>> better than the others.  Still, it doesn't really help you resolve the
>>> problem with the other calls.
>>>
>>> With this info, is there anything I could test to solve the problem?
>>>>
>>>
>>> No. There is no way for you to solve the problem directly.  As I already
>>> said before, you will have to work with your service provider to remedy the
>>> problem.  (And, even then, they may have only a limited control on the
>>> factors involved.)
>>>
>>> Thanks,
>>>
>>> Lee.
>>>
>>>
>>
>>
>