[asterisk-dev] T38 Gateway As A Codec Translator (#11761)
gregnietsky at gmail.com
Mon Jan 14 00:12:37 CST 2008
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
i spent most of the weekend scratching into the gateway bits in Steve's
spandsp and feel this is feasiable.
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
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
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.
More information about the asterisk-dev