Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

T.38 FoIP issues

Status
Not open for further replies.

Kcissem

IS-IT--Management
Nov 16, 2007
11
US
This is probably only my second or third post here, but I have issue with T.38 reliability just can't seem to narrow down. first an explanation on how things are setup

Mitel 3300MXEII (local)
Mitel 3300MXEII (Local resil)
Mitel 3300MXEII (Remote)

All three are clustered together, all calls go in and out of the local system to the remote site over a GIG dedicated internal link(We have Inet connecting all of our sites.), VoIP works fine but when it comes to faxes using T.38 we seem to have about a 10 to 20% failure rate. There are about 35 faxes currently at the remote site with 16 T.38 licenses in each system. I've tried everything, even mitel tech support is clueless so i'm asking here is there anything that can be done to make it more reliable? any tips would be appreciated, thanks
 
Hi,

I had similar problems as you and in the fax form I saw the choice of NSF on/off. Wondering what NSF was I googled it and found an article titled "What is NSF and why should I care?" Google that phrase and you will get the article. It's very interesting.

Bottom line is if two fax machines negotiate a non standard protocol, t38 will fail. After I changed the NSF flag to disallow NSF, my failure rate went almost to zero.

Hope this helps
 
Any logs?

How are the failures defined? Call doesn't initiate? Call drops after first page, call drops mid-page, etc. What data rates are your machines using? Is it calls to certain fax machines? From certain machines? Incoming only, or outgoing only, or both?

These are just the start of questions to find the answers to before you can being to narrow it down.
 
Northportphoneguy

NSF is already disallowed

IrwingMFletcher

How are the failures defined?

Usually in the logs t.38 unexpected result errors, some t38dsp failed to starts, Mitel took the system diag to their design depart but to no avail, the ended up closing the ticket without it being resolved. I have yet to open another one as i'm exploring other options. I believe mitel's version of t.38 is udp. of course udp is not guaranteed so i'm sure this has something to do with some of it anyways.

Call doesn't initiate?

Yes it does both machines on the receiving and sending ends will show it starting to connect but when the errors happens it seems the handshake does not complete both machines will stick at connecting until the sending machines thinks it's unavailable or busy.

Call drops after first page?

never seen this happen yet same for your next question

What data rates are your machines using?

most of the faxes are either v.17 or v.34 there are no correlation between the fax speeds that have the issue, appears to be more or less random, but i lowered the max speed in the fax config form to 9600 and has seemed to help a bit.

Is it calls to certain fax machines?

not necessarily but most (not all) are brother intellifax 2900 series that have the issue.

the issue actually happens on both ends, sending or receiving, i currently made a workaround for the sending part as i forced the faxes to go out the local backup PRI instead of over the network back to the local site. My last resort is just making the site change their fax numbers to the local DID's.
 
Ok, so when they fail, they fail during call setup, not during transmission, correct? If that's the case, have you done any sniffer captures to determine if the streams were established?

If it happens with a family of machines, then it's most likely a protocol problem, a failed trace would help.

Yes, it's the UDP version, if you suspect a network issue then you could try to increase the redundancy. Although from what you are saying, I doubt it's a packet loss issue.

 
You might try setting the baud rate to 14,400 and turn off Error Correction Mode on the fax machines. No guarantee this will work for you, it has helped on some of our machines before. We are switching to a fax server to try and eliminate these issues.
Hope this helps.
 
I don't suspect any network issues, our network is pretty top notch through out the system, but i have had our Network department check the link between the 2 sites and everything passes ok there. as to going with 14,4 that is the default my system was set at, i lowered it to 9600 and things have gotten better. ECM is already off.

But with lowering to 9600 and among some other changes things seem to have gotten better. since monday afternoon the fax situation has been about 95% successfull which i can live with that considering you will never get 100% especially with UDP. Today (Friday) is the real test though as that is when i seem to get the most complaints. Thanks for the suggestions. I do have another question which i will open a new thread for it.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top