[Home]

Summary:ASTERISK-17180: [patch] [new feature] support for T.38 pass-through
Reporter:under (under)Labels:
Date Opened:2010-12-29 11:01:33.000-0600Date Closed:2014-08-12 11:19:46
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_h323
Versions:Frequency of
Occurrence
Related
Issues:
is related toASTERISK-20465 Updates to make work with latest SVN revisions + T.38 support + interoperability improvements + bugfixes
Environment:Attachments:( 0) t38.diff
Description:Using already done work on behalf of ASTERISK-1231380 and ASTERISK-1510285, I'm going to prepare T.38 pass-though support for chan_h323.
This includes:
1) T.38 capabilities negotiation (as done in chan_sip)
2) SIP<->H323 T.38 pass-through
3) support for RxFax(), TxFax() applications.

I have already a patch that works with hylafax + t38modem + RxFax()/TxFax().
I need to make more tests before posting it here.

I will prepare patch(es) for 1.6.0.21 (we use it in production custom system).
I can provide support in case if anyone interested has issues during tests.
However I think I won't be able to provide patches for other Asterisk versions due to lack of time. But it shouldn't be difficult to merge to other Asterisk version for anyone interested because chan_h323 is not heavily developed during recent years.

Please let me know if anybody is interested in testing/using/reviewing.
Comments:By: under (under) 2010-12-29 14:49:33.000-0600

forgot to say, that I've also implemented a switch back to voice mode after T.38 fax is transmitted.
By: Leif Madsen (lmadsen) 2011-01-04 16:10:33.000-0600

New features need to be developed against trunk only. Also you might want to look at chan_ooh323 as that is being supported by an external developer. Not much work (if any) is being done on chan_h323.
By: Leif Madsen (lmadsen) 2011-01-04 16:11:20.000-0600

Marked as Feedback until there is something to test or go on here.
By: under (under) 2011-01-05 04:11:45.000-0600

Hi, lmadsen.
Yes, I talked with chan_ooh323 developer already (his nickname is "may").
And actually I based on his implementation.
I'll try to prepare patches for trunk as well.
By: under (under) 2011-01-11 17:44:11.000-0600

Initially I tested with hylafax + t38modem, but they're too buggy to rely on.
Therefore, for testing following setup has been used:

1) 2 Asterisk boxes (AST1, AST2)
2) AST1 is in terminal mode. SendFax(), ReceiveFax() applications are used.
3) AST2 is in loopback mode. Using Dial() application it sends calls back to AST1.
4) calls are triggered with call files
5) Before and after SendFax(), ReceiveFax() in both directions voice is played with SayNumber() application.

Following modes have been tested:

1) SendFax (AST1) ->  (H323/fastStart) -> Dial (AST2) -> (H323/fastStart) -> ReceiveFax (AST2)
2) SendFax (AST1) ->  (H323/slowStart) -> Dial (AST2) -> (H323/slowStart) -> ReceiveFax (AST2)
3) SendFax (AST1) ->  (SIP) -> Dial (AST2) -> (H323/fastStart) -> ReceiveFax (AST2)
4) SendFax (AST1) ->  (H323/fastStart) -> Dial (AST2) -> (SIP) -> ReceiveFax (AST2)
5) SendFax (AST1, chan_h323) ->  (H323/fastStart) -> Dial (AST2, chan_ooh323) -> (SIP) -> ReceiveFax (AST2, chan_h323)
6) SendFax (AST1, chan_ooh323) ->  (H323/fastStart) -> Dial (AST2, chan_h323) -> (SIP) -> ReceiveFax (AST2, chan_ooh323)


For mode 5,6 to work I had to hack "max datagram" option for chan_h323 (similar to how it's done for chan_sip), because chan_ooh323 tells "max datagram" is 30 which is too small to exchange data for app_fax.

Results have been verified with Wireshark (checked switch to T.38 and back to voice, ports and media streams), transmitted .tiff file has also been verified with openoffice.


By: Alexander Anikin (may213) 2011-01-19 15:42:56.000-0600

Hi,

I used efax + openh323 version of t38modem  when i tested t38 support
in chan_ooh323, i think it must be more stable and flexible than hylafax + t38modem.
By: Alexander Vysokovskih (laowai) 2011-05-12 22:12:46

Hello,

Where can we get this patch?)
By: Gregory Hinton Nietsky (irroot) 2011-05-12 23:51:49

rather look at chan_ooh323 chan_h323 is on death row also look at ASTERISK-12667 / ASTERISK-17754 things are coming together nicely got customers using

Hylafax <-> t38modem <-> chan_ooh323 <-> [Gateway] <-> chan_dahdi

using t38modem V.2
By: under (under) 2011-05-24 16:47:21

Hi, guys.
I've uploaded the patch.

I've ported our existing patch for Asterisk-1.6.0 to asterisk-trunk.
So uploaded patch should cleanly apply to asterisk-trunk (r320715).

The bad thing about this is that I didn't verify that patch works ok (heh, have no time) for Asterisk trunk.
I'll be able to verify only when we move to Asterisk-1.8 in our production.
For Asterisk-1.6.0 this patch works for 6 months already.

Also this patch contains fixes from issue ASTERISK-1834591, because I'm not sure it will work as expected if this patch isn't applied beforehand.
By: Denis Kochmashev (dkochmashev) 2012-02-22 05:12:36.332-0600

Hello! I've ported this patch to Asterisk 10 (SVN r356213).

Also made some changes for myself:
1) work with PTLib >= 2.8.4 & H.323 >= 1.22.0;
2) compile with DEBUG version of PTLib & H.323+;
3) H.323+ behave correctly when switching to T.38 (InternalEstablishedConnectionCheck hack);
4) correct processing of progress_setup and progress_alert config options;
5) hack to make RFC2833 DTMF work with Avaya Communication Manager;
6) some more corrections.

So I only can provide this patch with all above changes. Is anyone interested in testing?

By: Matt Jordan (mjordan) 2014-08-12 11:19:40.412-0500

Unfortunately, {{chan_h323}} has been unsupported for a long time and was marked deprecated. Due to there being a supported replacement channel driver, {{chan_ooh323}}, {{chan_h323}} was removed from the Asterisk source tree in Asterisk 13:

http://lists.digium.com/pipermail/asterisk-dev/2014-June/068363.html

As such, this issue will be closed out as "Won't Fix". I recognize that this issue has been open for a long time, and as a project, we're sorry that the patch attached this issue didn't receive more attention. We've made some changes in the way the patch process works to try and alleviate the issue of patches not receiving attention; for more information, see [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process] on the Asterisk wiki. If you still need H323 support and are using Asterisk, I'd recommend switching to {{chan_ooh323}}, as it has a dedicated module maintainer who can help with patches to that channel driver.