T.38 and fax modem pickiness

[Anonymous]

Hullo!

We are a small, regional ISP and ITSP, deploying our first ever TA900-series device (912 2nd-gen) for a new customer.  They have an old PBX that they don't want to replace at this time which only has FXO trunk ports.  They also have a dedicated fax line, so we need to support that.  To that end, I have been playing with T.38 support on the TA900's FXS ports.

We successfully pass T.38 through to our wholesale term providers using other T.38-capable ATAs all the time, so I figured that as long as the T.38 gateway implementation on the TA900 was solid, interop should not prove to be problematic.  But I had a heck of a time successfully making or receiving faxes through the FXS ports on the TA.  In essence, I was unable to receive a single fax as long as the session was successfully re-INVITEd to T.38, and I could only successfully send a fax via T.38 if I forced the modulation rate down to V.29 9600bps.  If a T.38 re-INVITE never took place and the call remained on G.711u, I could generally send or receive successfully, but during an actual T.38 call, my fax modem would repeatedly send back Failure To Train during a receive no matter how far down the modulation ladder the other end would go, and when sending, it would successfully train @ V.17 14400bps and start to send the first page, but then the receiving end would spontaneously drop the call in the middle of transmission.  Forced to V.29, though, transmit was nearly always successful.

I went through both your "T.38 Protocol in AOS" configuration guide as well as your "Configuring and Troubleshooting Fax and Modem Calls in AOS" document, and tried all manner of things.  I made sure that redundancy was enable and configured.  I tried your recommended impedance setting, and increased both the receive and transmit gain on the FXS interface that the fax modem was attached to.  I tried so-called "static provisioning" with echo cancellation forced completely off.  Nothing made any difference.  And yet if I take the exact same fax modem and connect it up to one of our other ATAs, T.38 faxes work perfectly fine.

We are using Asterisk to face customers and provision our SIP trunks, and I thought perhaps there was an interop issue with Asterisk T.38 passthrough, so I even went to the extent of configuring the TA912 to directly peer with one of our term providers, cutting Asterisk completely out of the equation.  Same issues.

On a whim, though, I ended up attaching a different fax machine to the same port on the TA900, and...son of a gun, it worked.  After that, I set everything back to defaults (including impedance and audio gain levels) and only enabled T.38, modem passthrough, and T.38 redundancy, and still I could send and receive at 14400bps all day long from this other fax machine.

?!?

So it would seem that some modems have a sensitivity to the T.38 gateway implementation on the TA900 that they don't seem to have towards other implementations, while modems that are perhaps less picky work okay with it.  I don't know what to expect when we finally install this TA for the customer; I don't know what kind of fax machine they have, and hopefully their machine ends up working just fine with the TA, but if it doesn't, what are the next steps that I can take to try and diagnose and mitigate the issue?  I suppose as a last-ditch, I could offload the T.38 duties from the TA900 and install one of our normal ATAs as a one-off for just the fax machine itself, but I'd like to avoid that if at all possible.

The TA912 shipped from the factory with R10.9.6, but I updated that to R11.4.6 with no change.  Attached you will find what is basically the running config of the device (with 4 FXS ports enabled which are configured to emulate a POTS hunt group), scrubbed of usernames, passwords, IP addresses, and so forth.

Thanks for any leads,

-- Nathan

EDIT: I forgot to mention that the fax modem in question that is struggling with the TA900's T.38 implementation is one based on a Conexant CX93010 chipset.  It is a non-controllerless USB modem connected up to a Windows 7 machine running Windows Fax and Scan.  I have no idea what lies underneath the working fax machine, which is a big commercial all-in-one HP LaserJet (MFP M630).

Message was edited by: Nathan Anderson

[Anonymous]

Hello Nathan,

I see there is a ticket open with Technical Support regarding this.  I think it will be easiest to work the ticket with Support and then we came come back and update this post when we have a resolution.

Regards,

Geoff

[Anonymous]

I opened up a ticket about a week after posting this when I got no feedback here.  I agree that it would be best to run this up the proper channels, but your web ticketing system is whacked.  I keep trying to update the ticket in order to replicate my forum post on it and the web site keeps throwing back an error that "There was an error fetching your tickets" (and that's literally all it says), which doesn't make any sense as I was just looking at my ticket and merely tried to submit an update to it.  I reported this to the web developers but have not yet heard anything back.  Been happening for well over 24 hours now.  Very frustrating.

-- Nathan

[Anonymous]

we had a similar situation at a hospital where an old type fax machine would work fine but their new machines would fail 99% of the time. You may want to try 2 things:

1- set the rings on the fax machine to  answer after 3 rings

2- disable caller ID on the line.

It seems that the caller ID info tone which comes in on the 1st ring would still be present when the newer fax machines picked up, thus causing connection issues. We were unable to change the number of rings on the customer's machines, so disabling caller ID was the solution.

Here is an example out of our ONT, but your 900 should utilize similar commands (the phone number has been replaced with "x's" for customer privacy):

voice user xxxxxxxxxx

  connect fxs 2/1

  description "Metaswitch"

  no call-waiting

  block-caller-id

  did "xxxxxxxxxx"

  sip-identity xxxxxxxxxx T01 register auth-name "xxxxxxxxxx" password "xxxxxxxxxx"

  modem-passthrough

  t38

  t38 max-rate 9600

  codec-group 711

I hope this helps

[Anonymous]

Very interesting, and thanks for the response.  I will give your suggestions a try; however, I do not hold out much hope that my problem has the same underlying cause as yours, because the fax modem in question is already set to answer after 2 rings, and I have a lineman's set attached to the 66 block which I have already used to verify that the CLID FSK blast has already ceased well before the modem answers the call.

Thanks again,

-- Nathan

[Anonymous]

To follow up on my last reply, I can confirm that turning off CLID transmit and increasing the ringcount before answer on the receiving fax does not make a difference.

I am making some DSP captures for Support; stand by...

-- Nathan

[Anonymous]

Unfortunately, after a couple weeks of back-and-forth with support, it got kicked up to engineering, and then a couple more weeks went by where nothing was coming back, and finally we had no choice but to install the TA for the customer with this left undiagnosed.  We simply ran out of time.

*Fortunately*, it turns out that the customer's fax machine seems to have no problems with the fax implementation in the TA900's DSP.  Should the issue present itself in the field, I was prepared to work around it with a "plan B" that involved a separate TA device from another vendor for just the fax machine, but thankfully it did not come to that.

I would still like to see this addressed at some point since I am now a bit skittish knowing that there is a *possibility* that we may encounter random fax machines that don't like something about the TA900's implementation, but at this time we do not have a spare TA9xx to play with on the bench.  So I guess we just keep opening the ticket whenever we have a new one to install...

-- Nathan