[Asterisk-Dev] Fax support?

[Steve Underwood]

Bruce Ferrell wrote:

> Leo,
>
> You might want to have a look at the contrib module on openh323.org 
> (use the sourceforge CVS, openh323.sf.net)
>
> There is a t38modem implimentation there.  I've had it work and had it 
> fail as well.  You MIGHT wnat to look at the RTP implementation it's 
> using.  I suspect the problem might be there.

T.38 doesn't use RTP, although there are proposals for making that an 
option.

> Leo D'Angelo wrote:
>
>> Hi all,
>>
>> I'm new to this list.  I did search around on the web about fax support
>> using *.  I found spandsp, and got it running on my machine BTW...
>>
>> Unfortunately t.30 will not work reliably over an IP network...  I 
>> was the
>> CTO for jFax and eFax and we spent A LOT of time researching these 
>> issues...
>> Anyway, I am willing to integrate a T.38 implementation.  My 
>> question:  Is
>> anyone already working on this?  If so we can collaborate.  If not 
>> I'm glad
>> to do it...
>>
>> I did notice that spandsp was implemented as an application.  I 
>> *think* that
>> a T.38 implementation should be implemented as a channel (to provide
>> interoperability with cisco routers, etc...)  Anyone agree or 
>> disagree with
>> this approach?
>>
>> Thanks in advance,
>>
>> -LeoD
>
Hi Leo,

I produced spandsp as the first step towards a T.38 facility for *. 
Right now I am finishing off the next major round of additions to 
spandsp - its own FAX compression/decompression routines, V.17, modem 
noise performance improvements, class 1 FAX modem interface for HylaFAX 
compatibility. When this has stabilised I want to make T.38 work.

I think a channel is the wrong solution, but I'm not yet sure. If they 
had been sensible, and used RTP for T.38, a channel would definitely be 
wrong. Since T.38 uses its down protocols on the wire I am not sure. It 
seems like it should be a codec, as it translates between audio, and 
another representation of the audio. However, since it needs its own IP 
protocol stuff that might be wrong. Perhaps a channel for the wire 
protocol, and a codec for the core T.38 protocol and modem part is the 
right solution. Then, if the RTP version of T.38 takes hold, the codec 
part can then just plug into the existing RTP channel. I haven't had the 
time to think this through properly, yet.

If you would like to help with the protocol stuff, as I continue to 
develop the DSP side, that would be appreciated.

Regards,
Steve