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

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

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*