Intermittent Incomplete Faxes 2

[ThurmanB]

I'm having intermittent sending issues with fax machines at multiple sites. I'm not having any voice calls disconnected, just faxes either not sending or sending incompletely. After checking a list trace, it looks like the trunk member is going idle in the middle of the fax, and then causing a timeout on the system. The kicker is that it looks like it is happening on multiple trunks, ISDN (for Local Calls) and CO (Long Distance). Another interesting fact is that I can dial the TAC for the appropriate CO trunk and it will send perfectly, but if I dial like the end user (9 1 xxx xxxx) in which case it would normally access that trunk, it may or may not fail. I cannot try a similar test with the ISDN trunks because I cannot set dial access on them. I've attached photos of the failed list trace. I appreciate any input.

 

[kyle555]

It would appear that trunk 11/34 hung up, and your fax extn 5395 picked up again, did nothing, and got a off hook dial timeout.

Presumably GW 16 and PN1 are in different places/regions 16 and 1. Based on the line at 10:15:37, I'm presuming your 729 first and the gateyways step up to 711 when they hear the fax tones. I suppose in your codec set you could try "relay" instead of "passthru"

I normally don't care about packet loss when it's 1 or 2, but you've got the call termination <10 seconds after dropping your first packet or 3. maybe they're 56K faxes and the other one is on a bad IP network too?

Try relay in the codec set, which makes the gateway DSPs do the heavy WAN haul work so decent fax tones are regenerated on the DSP local to the trunk you're using and not relying on the fax on the other end of the WAN to send over once a packet drops.

That, or slow your fax machine modem down a bit. Could help too.

 

[ThurmanB]

Thanks for your help!

I will try that and post here again with the results.

 

[jimbojimbo]

There are a large variety of factors impacting your ability to get a FAX to send/receive successfully.

1. Software Version - CM7.0.1 is significantly different than CM5.2.1. The ability to support T.38 FAX Relay with Error Correction Mode (ECM) for example is not available in CM5.2.1

2. Cabinet/Media Gateways - Cabinets use TN2302/TN2602 DSP resources. If you any TN2302 V3 get rid of them. TN2302 V11 or higher and TN2602 support FAX Relay but do not support Error Correction Mode. G430/G450s require MP120 or MP160 DSP resources installed to support FAX Relay with ECM. The best combination is (2) G4x0 with MP120/160.

3. Firmware should be at the latest. There have been numerous "fixes" of the years.

4. Network. If your dropping packets you have a problem. A deployment with adequate bandwidth and QoS implemented correctly should not be dropping packets. FAX relay with redundancy, while slower and utilizing more bandwidth, would be a better option in this case.

5. (does not apply here but adding it for clarity) SIP Service Provider - Some carriers support T.38 and some don't. Some have a companion service for T.38. You need to verify with the carrier.

 

[ThurmanB]

Thanks Jimbo and Kyle.

As an Update, changing my codec-set to Relay did remedy the issue. However, since nearly everything I have is out of date, it's not surprising I was having issues in the first place. I've only recently inherited this system, and I'm pretty new at this so I greatly appreciate the help.

I am currently on CM5.2.1 and will be upgrading ASAP, Including firmware for GWs etc. . .

I will be looking into all of your recommendations to ensure the highest quality.

Thanks again, Y'all.


EDIT: for Clarity