Re: [hylafax-users] faxing over sip

[Robert Moskowitz <rgm@xxxxxxxxxxxxxxx>]

Lee Howard wrote:
> The idea behind T.38 is comparatively rather simple, too: skip the 
> entire modulation/demodulation process (like with G4 Fax), but 
> communicate over a VoIP channel instead of the PSTN. The problems with 
> this are, unfortunately, plentiful - not impossible to work around - 
> but certainly plentiful.
Particularly with the ITU still in the driver's seat. T.38 is much like 
the One Ring.
> First, VoIP channels use UDP/IP as a medium (to keep the call as 
> real-time as possible)... and so packet loss (jitter) is almost 
> inevitable unless you can control the entire network path and ensure 
> that loss will nearly never occur. T.38 compensates for UDP jitter by 
> allowing T.38 endpoints to add "redundancy" into their data 
> communication. Thus every piece of data may be retransmitted several 
> times in sequence in an expectation that not all packets will be lost. 
> Unfortunately not all T.38 equipment/software uses enough redundancy 
> by default for many applications to work without a hitch. Furthermore, 
> redundancy does not guarantee against packet loss, so jitter may still 
> occur depite even large amounts of redundancy. 
One solution to solve all of our past solutions.
> I don't think that anyone is saying that it won't ever work. What 
> we've been saying is that it's not reliable.
Windows is not reliable. Hey, even my linux system hangs once a month! 
And don't forget GSM.

What is 'reliable enough'?
> Because you cannot usually control all the factors involved, and 
> because many of them will work against you (i.e. UDP) by their nature, 
> it's difficult (if not impossible) to reliably reproduce that working 
> scenario in any other arbitrary environment. It may work for you at 
> one place, but it may not work at another, and if it does then it's 
> misleading to indicate to others that they should be able to expect 
> the same outcome as you.
One my greatest complaints against the IETF, IEEE, ITU, etal is the 
engineers there are GREAT at turning dials and tuning things to 'work 
well enough'. It takes significant political will to take a new course 
(or significant market clout).
> I try to cover this in detail here:
>
> http://hylafax.sourceforge.net/docs/fax-over-voip.pdf
Great paper. I once found some excellent information on hylafax.org (or 
a wiki?) on explaining things like HLDC, V.34, T.38, etc. But can't find 
the link now.
> Well, first of all, IAXmodem was intended to work over the loopback 
> adapter. It was never intended to be used over a WAN, and even to some 
> extent never over a LAN, either. I have tried to compensate for things 
> in IAXmodem as much as I can, but there's only so much that can be done.
That is the unfortunate result of using IAX. People actually expect it 
to work over a WAN jsut like a real voice connection.

No matter what disclaimers are used, there will be those of us that will 
stretch the envelope and then others that think that there are no limits 
(talk to Vint Cerf about the Interplanetary Internet! I bet once Vint 
gets it up and running, people will be trying to send faxes from Mars. :) ).
> Sure, variable latency is something to handle. It means that packets 
> ordered ABCD may arrive as CBDA... however, a fixed-length, short 
> buffer in the device can easily overcome the vast majority of this 
> kind of thing. I've done that in iaxmodem's "jitterbuffer"... however, 
> over time I've found that in most cases if a UDP packet is late... 
> well, it won't come at all... it got dropped. 
It is called RED: Random Early Discard. I was there when it was deployed 
overnight to BREAK CeeUCeeMe in Europe, and to finally get the attention 
of the programers over at CMU that the Internet was not their's to take 
over for streaming content. And I really mean that RED was deployed to 
STOP a UDP application from living without packet loss.
> So in most cases if C arrives before A or B it means that A and B 
> aren't coming at all, and I've found that the DSP actually can cope 
> without them far better than it can cope with any packet-loss 
> concealment that such a buffer use would typically imply.

John Crowcroft once commented that at times he was sorry he created the 
Open Sockets call for BSD, as it isolated the programmer from the 
realities of the network.



____________________ 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*