Fax Anomilies - with 20+ pages

[stfan]

We are experience problems with outbound faxing of documents that are in the range of 20+ pages. The transmission fails, usually with a message relating to poor line qaulity. We have done some extensive testing and I believe the failure occurs within Shoretel.

The fax machines that fail most often are low end Brother machines. We also have Panasonic machines that seem to work more consistantly, but they also fail on occassion with the larger documents. (I don't think the brand of nmachine is a factor in this case, but I mention just for the FYI)

I have read where PRI trunks are prefered for faxing (over analog trunks), but in our testing, it appears we have a higher success rate going out over the analog ports. (Here also, I don't think this is the root of the problem, but FYI)

We have the fax machine extension isolated into a Fax_User_Group and have all the potential interferance turned off and so we can toggle between analog or PRI trunks for testing.

The test scenerio used the same machines and results have been;

1) Machine on outside POTS line --> machine on outside POTS line = OK
2) Machine on outside POTS line --> machine on internal ST ext = OK
3) Machine on internal ST ext --> machine on internal ST ext = Failed
4) Machine on internal ST ext --> machine on outside POTS = Failed

5) Machine on outside POTS line --> a DID number associated with an internal ST ext, and that ST ext is forwarded (via an analog trunk) to an outside number going to a fax-to-email service = failed.

6) Machine on outside POTS line --> a DID number associated with an internal ST ext, and that ST ext is forwarded (via a PRI trunk) to an outside number going to a fax-to-email service = failed.

When I say Failed, the receipient does receive some of the pages, but the transmission stops at about page 17-20.

At some point we would like to go with our own internal fax-to-email solution, but if we can't get this to work reliably through the ST now, it won't work when we do fax-to-email.

Our vendor does not recommend putting fax machines on the ST, but it is documented in the manual and other people do it, so I feel there has to be a way to resolve this.

Any thoughts, comments or commiseration are appreciated.

[Forum]

Faxes require ZERO packet loss. That is why most of us don't care for faxes on the network. Maybe when FoIP is more widely accepted, this will change.

You could try to locate the Call GUID, and track it doen through some of the TCC logs to see if there was any packet loss. I had to do this for a Paging issue I was having.

[Jason Learmouth]

I'd double check that the extension is configured as a fax extension and also that the fax CODEC is G.711.

If you are seeing more failures on the PRI then it could be related to gain levels on those trunks. TAC can record the fax at the trunk switch and tell you if the levels are good enough or not.

Are the extensions and trunks at the same site?

[Ian Stewart]

We are experience problems with outbound faxing of documents that are in the range of 20+ pages. The transmission fails, usually with a message relating to poor line qaulity. We have done some extensive testing and I believe the failure occurs within Shoretel.

If you are attempting to fax over the PRI with low line quality as the error, you could try the 3.1 khz fix.

On the HQ server open regedit.

HKEY_LOCAL_MACHINE\SOFTWARE\ShoreLineTeleworks\Tel ephony Management Server\Settings

Create a new reg string called SwitchDebug with the value debug_options send_3_1_khz_audio 1.

Note: the period at the end of the string is required for parsing purposes

Wait two minutes so that TMS can propagate the new information to the switches.

We have had no faxing problems after this fix was applied.

[MagnaDon]

We already have a SwitchDebug string. Can I put multiple values in the data string? What would the syntax be?

debug_options timeout_overhead_paging 60. debug_options send_3_1_khz_audio 1.

or something else???

[stfan]

Sorry for the delay in updating this thread...

We had verified that the extension is properly defined as a fax extension and also using G.711. We do not experiencing any errors on the PRI itself. We are not going fax to fax over the network - this testing is all to outside numbers via local POTS or PRI. And we have now narrowed the test to local POTS only.

What we have stumbled on is that 20+ faxes will be received completely if the fax is received via a POTS trunk and that POTS trunk and the fax extension are on the same ST switch. We are using 120's.

However, another odd other scenario we realized is that short faxes are received fairly quickly @ 3-5 seconds per page. However, as the fax increases in page length, the time per page becomes disproportionately longer, as much as 60+ seconds per page. (We are using a standardized fax test page from one of the fax machine vendors and sending 20+ copies of the same page.)

So, it is kind of working, but not to an acceptable level for a work horse fax machine or fax server hung off the ST system.