[Asterisk-Dev] Re: T.38

[Orehov Pasha]

Steve Underwood wrote:
> Matthew Boehm wrote:
> 
>> Jerris, Michael MI wrote:
>>  
>>
>>>> Paul Cadach wrote:
>>>>     
>>>>
>>>>> Hello,
>>>>>
>>>>> 5) T.38 support;
>>>>>       
>>>>
>>>> Yes. I feel this is a must for 1.2. People have been waiting
>>>> a long time for this. T38 is the only reason why we purchased
>>>> a Cisco 5300 a few months ago instead of another asterisk box.
>>>>     
>>>
>>> A must as in you are offering to do it or pay for it, or a must in
>>> that we should never release 1.2 until it is complete.  I don't think
>>> we can realistically hold up anything for T.38.  If someone is
>>> willing to make it happen, great.  I will put my name firmly in the
>>> that would be really nice column.
>>>   
>>
>>
>> Suposedly Steve Underwood has been working on it for many months. He
>> recently told me that he was close to completion. I've sent him many many
>> emails offering to help test/debug/etc but they always go unanswered. 
>> There
>> is $3000 bounty in place.
>>
>> At the very least, T38 pass-thru should be added. It seemed very
>> "microsoft-ish" to me when I tried to send T38 thru asterisk and asterisk
>> said "what the crap is that? deny!"
>>  
>>
> Do you understand what doing T.38 passthrough really means? Many people 
> seem to think it just means adding another codec to the SDP stuff. Its 
> actually a new transport (since it usually uses UDPTL and RTP is rarely 
> supporetd). The SDP stuff is messy, too, as the SIP implementation in * 
> is far from complete and generic. What I am using at the moment is more 
> of a fudged SDP to get something working, than a proper solution. To do 
> passthrough properly you really need to allow for talking between UDPTL 
> and RTP. However, the RTP version of T.38 is still so rare it can be 
> left for the moment. In the extreme case you should really allow for 
> talking between TCP, UDPTL and RTP. However the TCP version of T.38 is 
> different enough to make that tough.
> 
> If passthrough was trivial I would have released it early in my T.38 work.
in h323 forpassthru it means additional codec type. Please add 
infrastructure to channel.c and publish as external patch and it will be 
fast to add chan_-private at first solutions to separate channels.
I hope. :)
chan-common is next.
t38 termination is more next.



also please think about passthue of additional data streams as t.120 in 
H.323