|Summary:||ASTERISK-11094: [patch] T38 support for SendFax/ReceiveFax|
|Reporter:||Dmitry Andrianov (dimas)||Labels:|
|Date Opened:||2007-12-21 06:57:44.000-0600||Date Closed:||2008-02-20 16:45:58.000-0600|
|Environment:||Attachments:||( 0) appfax-v3.patch|
( 1) asterisk-t38.patch
( 2) v4-appfax.patch
( 3) v4-asterisk-t38.patch
( 4) v5-appfax.patch
( 5) v6-appfax.patch
( 6) v7-appfax.patch
( 7) v8-appfax.patch
|Description:||Adding T38 support to SendFax/ReceiveFax applications. See Additional Information for details.|
There are two patches:
* appfax-v3.patch for asterisk-addons/trunk rev 497 - modifications to the fax application
* asterisk-t38.patch - temporary (see below) patch for asterik/trunk revision 94396
!IMPORTANT NOTE! This patch is considered work in progress because it depends on not yet finished feature of Asterisk - ability to request T38 reinvite on a SIP channel.
Currently, the patch adds this ability itself (asterisk-t38.patch) but it adds it in a very rude way. It is clearly a hack. When file finishes his t38insanity branch and Aterisk will get official way of requesting re-invite, I will update app_fax to use that way instead and asterisk-t38.patch won't be needed anymore.
****** ADDITIONAL INFORMATION ******
1. T38 support added. When acting as receiver, as soon as we detect CNG tone, we request T38. IWhen T38 is negotiated (if it is negotiated), we switch to T38 mode. When acting as sender we do not offer re-invite (because spec says it is receiver side business) but if T38 is offered by remote side, we switch to it.
2. The regular (audio) fax re-implemented using Asterisk generators. This should have no consequences for ordinary users but it now allows "connecting" SendFAX to ReceiveFAX both running on the same PBX for tests.
3. 'd' option (debug) is removed. Now you control amount of debugging with the global 'core set debug' CLI command. Depending on the level, different things are logged:
0 - obviously nothing
1 - only the minimum from app_fax + SpanDSP protocol errors and above (warnings and errors)
2-8 - map to SpanDSP levels from SPAN_LOG_PROTOCOL_WARNING to SPAN_LOG_DEBUG_3 (see SpanDSP logging.h)
20 - display frametype/subtype of all frames received by app_fax
usually you need something like 'core set debug 3'
|Comments:||By: Olle Johansson (oej) 2007-12-22 00:59:03.000-0600|
We have not other app using a debug level above 10, propably not above 5 either. Do you really need that high debug levels?
Would it make sense to have a special T.38 debug, like sip/rtp debug commands?
By: Badalian Vyacheslav (slavon) 2007-12-22 03:31:42.000-0600
I use appfax-v3.patch for asterisk-addons (converted to branch use. diff is only use debug print function). Its work great for me. I wont test this patch, but in branch revision. May you add support for it? Thanks.
By: Dmitry Andrianov (dimas) 2007-12-22 05:34:49.000-0600
actually, currently I have a big gap in debug levels between 8 and 20 which does not change anything so of course I can move logging I do at level 20 to the level 10. No problem.
However, I chosen 20 intentionally - currently at the level 20 every received frame gets logged which produces flood on the console. So I chosen high level to save user from turning it on accidently. If it is Ok to have this happining on the level 10, I will adjust the code appropriately.
I'm not sure if separate T38 logging is needed because in case you troubleshooting something, you will need sip+rtp+udptl debugging anyway.
No, I'm not going to backport the application to 1.4 because the whole idea why I created SendFax/ReceiveFax application is to offer people _supported_ application which they get from official SVN and which chages appropriately to match changes in Asterisk code. Since 1.4 version won't be accepted by Digium there is no way to provide support for it - make and publish fixes etc.
However backporting is very easy to do. Please either contact Cache who already did it (I believe you know him) or do the patch yourself.
By: Dmitry Andrianov (dimas) 2007-12-25 09:35:54.000-0600
Tests revealed that the old "hacky" way to detect when T38 switchover is finished was way too hacky. I was waiting for the first UDPTL packet to conclude we T38 switchover is complete. Hoewver alot of devices wait for UDPTL packet from us instead so we were waiting for each other idefinitely.
Asterisk patch significantly extnded to provide access to "internals" of SIP t38 state to let me know when switchover is really complete. Updated the application & Asterisk patch;
These are REPLACEMENT for old patches so should be applied to freshly checked out source. (Or svn revert the previous patch).
By: Volnikov Ivan (ivan) 2007-12-26 01:38:25.000-0600
I have tested this updating. It [v4-appfax.patch+v4-asterisk-t38.patch] really works (testing on LinkSys SPA2102 with last firmware). I think that this very good decision for built in to Asterisk fax-server. Backport on 184.108.40.206 works too.
By: Gregory Hinton Nietsky (irroot) 2008-01-12 09:01:07.000-0600
here is somthing related id like to throw out here ...
could it be possible to set/introduce a codec AST_FORMAT_T38FAX as a possible codec and use this as the channels codec when T38 is negotiated this way we can write a codec_t38 that will perform the transcoding bits using steves T38 gateway bits in spandsp.this will keep the digium codebase clean from a licencing point of view as this codec can be added to the addons where send/recive fax is at the moment.
basicaly what a codec translator seems to do is convert a format back and forward into SLIN that is what the t38_gateway code does so i see this as a good marrige and the right place to put the T38 gateway bits.
this will allow calls to/from a T38 device to pass via any channel ie Zap/mISDN with no changes required to the asterisk core if the translator module is loaded (addons)
By: Dmitry Andrianov (dimas) 2008-01-12 09:46:09.000-0600
I think you need raise your question on the dev mailing list - how does such a design fits Asterisk.
I'm not failar with Asterisk codec infrastructure but I doubt such a thing is doable. This is because codec should normally operate on audio stream only while for T38 the codec would need convert SLIN audio to UDPTL.
By: Gregory Hinton Nietsky (irroot) 2008-01-12 10:32:19.000-0600
the way i understand it is the translator sits between the channels and passes data back and forward to the channels through there read/write bits.
The codec translators operate on frames that may or may not be RTP Zap/mISDN certainaly is not RTP and translation takes place a better example is perhaps woomera that uses sockets and can translate ...
this is what app_fax does but to/from a file to the T38 device it reads/writes frames on the channel.
chan_sip will need to be updated to set the codecs on the reinvite ...
but if app_fax can read and write data from a T38 device there should be no reason for dial to be able to brige a T30 <-> T38 call via zap and friends.
the structure of a translator seems to lend itself to this there is a private structure that will be able to store t38_gateway_state_t as it uses a buffer the call back t38_tx_packet_handler is suited to this ...
if the t38_gateway_state is null (pvt) init the T38 gateway (will be nice to use settings from chan_sip ie fill/ecm) frames will be read on both sides using t38_core_rx_ifp_packet/t38_gateway_rx and sent via t38_gateway_tx and the callback used to init the T38 gateway.
if app_fax is reading and writing T38 frames why cant they be transcoded on any channel ...
sure it can be hacked into app_dial this will not be accepted by digium (similar approach to callweaver) or a new T38Dial app can be knocked out (not ideal) if im on the right track then a addition of AST_FORMAT_T38FAX in frame.h some small changes in chan_sip to set the format to AST_FORMAT_T38FAX in the reinvite/SDP and asterisk should take care of the rest.
By: Igor Goncharovsky (igorg) 2008-01-28 22:16:50.000-0600
Latest SVN changes process_sdp function and patch for asterisk need to be updated.
By: Dmitry Andrianov (dimas) 2008-01-29 05:32:40.000-0600
Right there were lots of changes in SIP recently even including (good news!) some of the changes from v4-asterisk-t38.patch
However I gonna wait with updating fax patches for about a week or two. I want to cleanup required Asterisk changes I have and submit them as separate issue. This is because small changes tend to be commited more quickly. As soon (and if) the Asterisk changes are adopted, app_fax will be modified to use new API.
Yuu guys, who participated in the initial testing of T38 app_fax will receive new version for testing by email.
By: Dmitry Andrianov (dimas) 2008-01-30 03:04:21.000-0600
Ok guys, here is the new version. v5-appfax.patch is the patch for asterisk-addons only. What needs to be fixed in Asterisk core exist as separate issues on Mantis. Which means
!!!YOU HAVE TO APPLY THESE PATCHES TO ASTERISK FIRST!!!
Note to backporters. You will need:
1. define ast_debug in logger.h - see http://bugs.digium.com/file_download.php?file_id=14376&type=bug
2. define ast_tvdiff_XXX functions - see http://bugs.digium.com/view.php?id=11270
3. Apply fix for T38 state - http://bugs.digium.com/view.php?id=11630
4. Apply fix for T38 flags - http://bugs.digium.com/view.php?id=11239
5. Patch DSP in trunk with http://bugs.digium.com/view.php?id=11796 and then copy main/dsp.c and include/asterisk/dsp.h files over your 1.4 sources
6. Add T38 API as in http://bugs.digium.com/view.php?id=11873
7. Patch app_fax
With any patch I recommend you not taking the file from Mantis but getting corresponding diff from SVN because some patches were changed by committers. Good luck.
By: Dmitry Andrianov (dimas) 2008-02-09 04:22:07.000-0600
Patch updated to match changes in 11873
By: Dmitry Andrianov (dimas) 2008-02-09 04:55:24.000-0600
removed debugging accidently left in the code
By: Douglas Gillespie (douglasg) 2008-02-14 08:56:34.000-0600
Good work! What version does this apply too? Trunk? 1.6? Thanks..
By: Dmitry Andrianov (dimas) 2008-02-14 17:46:50.000-0600
By: Dmitry Andrianov (dimas) 2008-02-20 16:32:17.000-0600
Patch updated to match file's changes in T38 API as well as reorganization in the addons tree.
By: Digium Subversion (svnbot) 2008-02-20 16:45:58.000-0600
r533 | file | 2008-02-20 16:45:57 -0600 (Wed, 20 Feb 2008) | 6 lines
Add support for T38 to app_fax since Asterisk now has an API and way of doing things with it.
(closes issue ASTERISK-11094)
Reported by: dimas
v8-appfax.patch uploaded by dimas (license 88)