[asterisk-bugs] [Asterisk 0012380]: [patch] T.38 support for chan_h323 with t.38 - t30 conversion

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12380 
====================================================================== 
Reported By:                may213
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   12380
Category:                   Channels/NewFeature
Reproducibility:            always
Severity:                   feature
Priority:                   normal
Status:                     new
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  1.4  
SVN Revision (number only!): 112599 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             04-07-2008 19:33 CDT
Last Modified:              04-21-2008 20:06 CDT
====================================================================== 
Summary:                    [patch] T.38 support for chan_h323 with t.38 - t30
conversion
Description: 
Hello!

There is patch for h323 channel code which enable t.38 proto support,
translate t.38 packets to alaw sound packets. 
====================================================================== 

---------------------------------------------------------------------- 
 dimas - 04-21-08 20:06  
---------------------------------------------------------------------- 
Hmm...
I did not look at the patch itsel because I have no idea how H323 works
anyway but from your comments here it looks like what patch does is T38
gateway. And I believe that these things should be implemented differently.
Namely:

Step 1. trunk/1.6 should be taken as a base - there is new AST_CONTROL_T38
frame which allows channel driver to notify the core about T38 switchover
as well as core to request a switchover from the channel driver.

H323 channel should be modified to generate these control messages as well
as react on them. For ideas - grep chan_sip.c for "sip_queryoption" and
"AST_CONTROL_T38".

When done, it will allow app_fax from addons to send/receive faxes on H323
channels in addition to Zap and SIP ones. That is T38 termination will be
done.

Step 2. Bridging code (or not?) needs to react on AST_CONTROL_T38 messages
from channels relaying them to other leg. This way when H323 switches to
T38, it will cause the same switchover to be triggered on a bridged SIP
channel. This is something not done currently and there is something to
think about because lots of T38 options needs to be passed (which are not
passed in a control frame yet).

Step 3. Gateway (T38<=>audio) code should not be part of any channel
driver. I'm not really sure part of what should it be but probably a part
of core/bringing code. This way, again, the same code will be able to serve
any technology type - SIP/H323.


I understand that a already existin something is better that some theory,
however I see no point in making common things specific to different
technologies. This way we will end up in partially implemented T38 for
H323, partially (the other part!) implemented for SIP etc. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
04-21-08 20:06  dimas          Note Added: 0085788                          
======================================================================