Re: Can't send Fax but can Receive
Lee Howard <[email protected]> Wed, 18 Oct 2017 08:55:12 -0700
| Newsgroups | gmane.comp.telephony.fax.hylafax.user |
|---|---|
| Message-ID | <[email protected]> |
t38modem is difficult to get working these days regardless of your Linux choice. You can configure Asterisk to perform T.38, if that's what you want to do. But, consider that T.38 simply pushes the T.30 operation to your service provider or someone else. It does it in real-time, but in effect you're simply pushing your fax traffic to an on-line service provider... which was my suggestion in the first place. If you're going to outsource the T.30 operation why shackle them with the burden of doing it real-time? Thanks, Lee. On 10/18/2017 08:32 AM, FM wrote: > 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] > <mailto:[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 > <http://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] > <mailto:[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] <mailto:[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. >> >> > > >