HylaFAX The world's most advanced open source fax server

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [hylafax-users] limit to number of modem?



Peter Halliday wrote:

All,

I have been using hylafax for over two years. We are running RPM for hylafax version 4.2.0, which we are running it on RHEL version 4. We have been running two servers one analog with 16 modems and one using VoIP. We understand that VoIP isn't liked by all on the list especially. However, our application has compensated for the failure rate we have seen on VoIP.


Everyone wants to fax over VoIP, and so it's a very tempting ambition to attempt. In VoIP communications that pass over a non-QoS network (the internet) you often have this kind of scenario show up...

A -> B -> C audio packets are transmitted, the receiver gets them as C -> A. Note that B was dropped altogether and that the two packets that did arrive came out-of-order. Also consider that C arrived significantly later than it should have.

So the receiver has to compensate for this somehow, it has to do something with the time that transpires between the packet preceding A and the time A arrives, and then it has to buffer C until after A is played and then it has to guess at what B should have been. In a voice call you may not even notice this. If you do, it will sound like a short cut-out or a crackle... maybe... depending on how your system works.

Those audio "packets" are 20 ms in length. At 14400 bps that's 36 bytes (calculated, probably not exact) per packet. At 300 bps (the V.21 HDLC frames) you may get one corrupt byte, but you may not (maybe like a 50% chance there).

No matter how good your VoIP system is, it still had to conjur up 36 bytes for that lost "B" packet. It would have to be a lucky guess to get it right. So every time that happens in a high-speed image data portion of the fax protocol some of the image data will be corrupted or lost. Every time that happens during V.21 HDLC communication you may see an FCS error which will trigger recovery measures (either CRP or a frame retransmission).

Recovery from this problem requires two things: 1) ECM on both ends, and 2) a resiliant fax protocol driver on both ends of the connection. HylaFAX 4.2.0 isn't nearly as resiliant as is 4.2.2 is... so you should upgrade. But even then, the receivers that you send to will not all be as resiliant, and some destinations will fail... many calls will fail. It will cost you more in effort and time and retries than you're going to save.

Furthermore the VoIP codec you use may be compressed such that modulated data will get lost.

With the right codec and the right network control and configuration you *can* fax over VoIP successfully - but you can't include the internet in that equation (because you can't control it). So people get excited about faxing over VoIP (including the internet) because they hear someone say that they did it, but that environment was controlled or the person just got plain lucky. That leads 10 other people to then try to fax through their VoIP provider, only to find that it doesn't work so great.

We went to move all our lines to VoIP lines because of cost. As soon as we did, our error rate went through the roof.


And you want to blame this issue on the number of modems? It's because of the faxing-over-VoIP issue that has been long-discussed here. Believe us. Now you have first-hand evidence.

You can run HylaFAX with hundreds of modems. 16 will be no problem.

Lee.


____________________ HylaFAX(tm) Users Mailing List _______________________ To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi On UNIX: mail -s unsubscribe hylafax-users-request@xxxxxxxxxxx < /dev/null *To learn about commercial HylaFAX(tm) support, mail sales@xxxxxxxxx*




Project hosted by iFAX Solutions