[Asterisk-Dev] Fax support?

[Leo D'Angelo]

Hi Steve,

Thanks for the response.  I agree with your assessment that t.38 should be a
codec not a channel.  I was actually thinking of simply adding it as a codec
to the openh323 channel already provided with *...

I don't know enough about the structure of * (yet) to figure out how a sip
request for a t.38 codec would work if I implemented t.38 as part of the
h.323 channel...  Any advice?  Maybe it really needs to be a separate
codec...

I am happy to help in any way I can.  BTW)  spandsp is some impressive work,
how long have you been working on it?

-LeoD  

On 7/10/04 12:21 AM, "Steve Underwood" <steveu at coppice.org> wrote:

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