Remote fax

Discussion in '3CX Phone System - General' started by eagle2, Feb 20, 2013.

Thread Status:
Not open for further replies.
  1. eagle2

    eagle2 Well-Known Member

    Joined:
    Apr 27, 2011
    Messages:
    1,085
    Likes Received:
    11
    Any idea why remote fax extension could be not working ?

    Setup is the following: using Grandstream ATA adapter (HT70x or GXW40xx) or Cisco (Linksys) SPA (2102, 3102, 112, 122, etc.) fax is being registered as a fax extension and this is working normally, as expected. Provider is T.38 compatible, so faxes can be received also as e-mail. So far, so good - no issues. 3CX server is the latest V11SP4 running on MS Windows 2008R2 server.

    Deciding to move the adapter and fax machine into another location the problems start. The main and remote locations are connected via high-speed internet (100 Mbps), ping is less than 3 ms, VLAN or VPN is set between locations or a GRE tunnel (same network segment), no difference. The adapter registers normally to 3CX server, starts to send or receive a fax message and communication dies during negotiation phase (fax error: No carrier). Two fax machines can communicate and exchange faxes without issues over the tunnel. The problem is with external parties. I tried to disable T.38, to check whether G.711 passthrough will be better, unfortunately, no result.

    Fax machine in main location is fine, fax machine in remote location can send / receive faxes only to/from internal fax extensions.

    Any ideas ? Is fax communication so sensitive to distance between 3CX server and ATA ?

    Regards
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  2. lneblett

    lneblett Well-Known Member

    Joined:
    Sep 7, 2010
    Messages:
    2,083
    Likes Received:
    61
    Orlin -

    Are you using Mikrotik on this? I had a similar instance where all seemed to be fine, but router was shutting down port after a few seconds (don't really recall how many), but had to insert line to force port being kept open.
     
  3. eagle2

    eagle2 Well-Known Member

    Joined:
    Apr 27, 2011
    Messages:
    1,085
    Likes Received:
    11
    Yes, infact I'm using Mikrotik routers and tried various tunnels -- PPTP, IPsec, EoIP -- practically no difference in behavior. It looks like some kind of timeout appearing which kills fax transmission. Probably I need to run wireshark or similar utility to find the reason.

    BR
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  4. lneblett

    lneblett Well-Known Member

    Joined:
    Sep 7, 2010
    Messages:
    2,083
    Likes Received:
    61
    Hope you find it and if you do, please let me know issue and resolution. I have started to use Mikrotik more and more and like them a lot, just not as experienced on them as I need to be so am keen to learn when something unusual arises.
     
  5. eagle2

    eagle2 Well-Known Member

    Joined:
    Apr 27, 2011
    Messages:
    1,085
    Likes Received:
    11
    I really doubt the problem is Mikrotik related, I could test it with Cisco GRE or IPsec tunnel also.
    Fax transmission is working between fax extensions in main & branch office, so tunnel more or less or working.

    The problem is between branch fax extension and external party, I suppose a kind of timeout appears (or port closed, as you suggested), however I don't find any NAT related issues, no NAT involved (also I've checked all recommendations in forum threads).

    Best regards
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  6. GManNAtl

    Joined:
    Sep 13, 2012
    Messages:
    58
    Likes Received:
    0
    You definitely need to get both Wireshark and the T.38 trace logs out of the ATA to diagnose the issue. I would get a capture in front of the ATA by mirroring the LAN side of the MicroTik on the remote side. Make sure you are seeing the call negotiate T.38 at this point. If not, here is your problem. If it is not I would verify that the ATA on the local side is actually negotiating T.38. It could be 711, but working due to being in the same office. The VPN is going to introduce some latency which would affect 711. Also, check to make sure you have QoS setup properly in the tunnel. BTW, who is the ITSP?

    Worst case why not just receive the fax in the 3CX fax server at the main location. Then there are plenty of utilities to automatically check email and print them (If they even HAVE to be printed). This would at least solve the inbound part of the equation. Obviously, outbound is another issue.
     
  7. eagle2

    eagle2 Well-Known Member

    Joined:
    Apr 27, 2011
    Messages:
    1,085
    Likes Received:
    11
    Hi,

    thanks -- I agree with all your suggestions and specially about G.711 passthrough sensitivity. ATAs not always negotiating T.38.

    The ITSP (Mobiltel, part of Vodafone group in Europe) advised me to change MSS for the tunnel and I decreased it from 1420 to 1272 (after running some test utility recommending this value on the basis of estimating MTU of 1300 for the tunnel).

    This didn't affected the G.711 behavior, but stabilized in great extend the incoming T.38 faxes. Unfortunately no result for outgoing ones, but I see attempts for sending G.711 faxes for some reason. I will post feedback after some more tests.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
Thread Status:
Not open for further replies.