[asterisk-users] fax / t38 gateway

[JD]

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 <whelm at compuserve.com>  
>> 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
>
>