[asterisk-dev] T38 Gateway As A Codec Translator (#11761)

[Gregory Nietsky]

hi all just opened up a T38 Gateway scratch pad on mantis and will be 
submiting some code soon not sure if this is the right approach all 
comments welcome.
i spent most of the weekend scratching into the gateway bits in Steve's 
spandsp and feel this is feasiable.

Regards Greg

Ok this is somthing that may or may not be possible or feasiable but im 
throwing it out here and going to attempt to do just this ...

please note this is related and tied into the brilliant work by dimas on 
christmas day (0011614 <http://bugs.digium.com/view.php?id=11614>)

there will be a few things required for me to do to make it suitible for 
our application

1)Define T38 as a codec (change to frame.h add it as a audio codec)
2)Create a codec translator (codec_t38fax) that will do conversion to 
and from SLIN
3)to allow T30<->SIP(T38/UDPTL)<->IAX(RTP/T38)<->ZAP(ALAW/T30) ill need 
to allow this new codec to pass on RTP
4)Dial will need to be updated to allow MODEM/T38 frame types as voice 
... (AST_FORMAT_T38FAX)

this is a brief overview im sure there will be headaches along the way.
Additional Information 	due to licencing issues hacking T38 Gateway onto 
the Dial command is not feasiable and i do not feel that a second dial 
command just for T38 is justifiable.the architecture of the codec 
translators lends itself to this approach of using a translator for the 
T30(audio/SLIN) to T38(data) conversion.

the idea is as follows using Steve Underwoods spandsp add a codec_t38fax 
file to the addons package that will accompany the newly T38 enabled 
app_fax to handle the gateway function.

slintot38fax is is achived by reading a T30 frame passed to the 
converter from the Zap/mISDN/.... channel and writing it to a buffer via 
the t38fax gateway handler call back.

t38faxtoslin is achived by processing incoming t38 ifp packets and 
writing them to a buffer with the t38 tx function.

all of the above is relitivly straightforward ... what is not straight 
forward however is preventing licencing isues and initilising the 
private structure (t38_gateway_init) make_compatible will need to make 
sure the same private structure is is used on both channels (t38state) 
and will possibly need to be locked.all the T38 bits need to be kept in 
codec_t38fax in the addons/GPL side asterisk must however make sure the 
private structure for T38 is on both sides.

this all seems great in theory and if im missing something or if this 
proposal is not acceptable please let me know ... ill be working on the 
bits over the next few days if there no objections.