Steven's writeup is great and explains a lot of this. A shorter answer from a different perspective:
The folks that devloped the fax V.protocols took into acount typical copper problems like noise or echo. But what they never conceived of as even being possible is that a call might shift around in the time domain. Thanks to jitter/latency, the delay time of a call can change in the middle of the call. That isn't possible with copper technologies. This makes faxing over even G.711 a dice roll. IMO, with a sufficiently large buffer and a rock-solid quartz clocking system that goes way beyond what is typically seen, it might be theoretically possible to send a fax over VOIP. Let me know if anyone finds that anywhere. John Brendan Martens wrote: > Quite right... And so we can all stop repeating ourselves; Steven has > already done a great writeup on all this: http://www.soft-switch.org/foip.html > > Brendan Martens > > > On Oct 27, 2008, at 3:20 PM, Kristian Kielhofner wrote: > > >> On Mon, Oct 27, 2008 at 2:49 PM, Wilton Helm <[EMAIL PROTECTED]> >> wrote: >> >>> Thanks Brendan for the explanation. There is one other idea that >>> struck me, >>> but again, I don't know if it has any merit. My thinking is to >>> keep FAX as >>> FAX and electronic as electronic, rather than introducing a new >>> hybrid >>> approach. Obviously Entering FAX from an electronic source is as >>> old as the >>> FAX modem, and Exiting it electronically is as old as E-FAX, not to >>> mention >>> other alternatives. >>> >>> Is it feasible to simply specify the codec as ulaw or alaw >>> (depending on >>> jurisdiction, I forgot the g numbers) for calls originating from >>> the FXS or >>> whatever the FAX is coming from? Obviously, the bandwidth would be >>> higher >>> in that case, but you can't get around the laws of physics. Yes it >>> is lossy >>> compression, still, but it is the simple, predictable form of lossy >>> compression that the modem in every FAX machine already is >>> programmed to >>> cope with. The only problems I can see would be if the provider >>> who handles >>> the call refuses to accept that codec, or transcodes it to >>> something else. >>> I don't know the likelihood of either of these. >>> >>> Wilton >>> >>> >> Wilton, >> >> Many providers will "allow" you to do faxing via g711u/g711a (G711u >> mu-law is used in "T" countries, G711a a-law is used in "E" >> countries). Of course they will "allow" it - fax modems talk to each >> other just like we do. They're just doing it with much less tolerance >> to error and variations in the audio. The provider's gateways, >> however, should detect the fax tone and disable echo cancellation, >> etc. >> >> What this discussion is forgetting are the issues inherent with >> packet networks: >> >> - latency >> - jitter >> - packet loss >> >> Standard fax machines communicating via some ATA with a G711u RTP >> stream cannot correct for these situations. In some severe cases. the >> modems might not even be able to train. V.x modem standards were not >> designed for packet networks. For this reason many faxes (especially >> at higher speeds) will fail (depending on the state of the network) >> when using a G711*, "pass-through", or "clear channel" codec. >> >> You will have a much higher rate of success faxing with G711u over >> your LAN than a congested cable modem, for instance. >> >> That's what T.38 is for. It doesn't even use RTP, it uses UDPTL >> (UDP Transport Layer) or TCP (rare) to manage the transport of data >> and correct for transmission errors in various parts of the OSI stack. >> As we've said before the "support" for this standard varies and often >> times just doesn't work. >> >> - G711u will fail depending on the condition of the network. >> - T.38 will fail depending on the type(s) of equipment used. >> >> Faxing via VoIP is largely a crap shoot. However, it is important >> to focus on T.38 because I feel these interop issues can *eventually* >> be resolved. No one is ever going to "fix" the issues with packet >> networks*. That's why they are packet networks. We will have much >> better luck working towards T.38 interop. >> >> >> * Obviously they are some "fixes" like MPLS, etc, but that doesn't >> really help those of us trying to make do with the internet, for >> example. >> -- >> Kristian Kielhofner >> http://blog.krisk.org >> http://www.submityoursip.com >> http://www.astlinux.org >> http://www.star2star.com >> >> _______________________________________________ >> -- Bandwidth and Colocation Provided by http://www.api-digital.com -- >> >> asterisk-users mailing list >> To UNSUBSCRIBE or update options visit: >> http://lists.digium.com/mailman/listinfo/asterisk-users >> > > > _______________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > > _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
