Summary: | ASTERISK-16950: Asterisk not send fax to fax extension | ||
Reporter: | mbrevda (lazytt) | Labels: | |
Date Opened: | 2010-11-12 05:16:04.000-0600 | Date Closed: | 2010-11-22 13:42:13.000-0600 |
Priority: | Major | Regression? | No |
Status: | Closed/Complete | Components: | Resources/res_fax |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ( 0) 0018299.log2.log ( 1) dialplan-fax.txt | |
Description: | Asterisk isnt sending fax to fax extension: == Redirecting 'SIP/69.167.68.134-00000036' to fax extension due to CNG detection == Spawn extension (from-trunk, fax, 1) exited non-zero on 'SIP/69.167.68.134-00000036' ****** ADDITIONAL INFORMATION ****** Dialplan as follows: -= 7 extensions (39 priorities) in 1 context. =- moshe*CLI> dialplan show from-trunk [ Context 'from-trunk' created by 'pbx_config' ] Include => 'from-pstn' [pbx_config] -= 0 extensions (0 priorities) in 1 context. =- moshe*CLI> dialplan show from-pstn [ Context 'from-pstn' created by 'pbx_config' ] Include => 'from-pstn-custom' [pbx_config] Include => 'ext-did' [pbx_config] Include => 'ext-did-post-custom' [pbx_config] Include => 'from-did-direct' [pbx_config] Include => 'ext-did-catchall' [pbx_config] -= 0 extensions (0 priorities) in 1 context. =- moshe*CLI> dialplan show ext-did [ Context 'ext-did' created by 'pbx_config' ] 'foo' => 1. Noop(bar) [pbx_config] Include => 'ext-did-custom' [pbx_config] Include => 'ext-did-0001' [pbx_config] Include => 'ext-did-0002' [pbx_config] -= 1 extension (1 priority) in 1 context. =- moshe*CLI> dialplan show ext-did-0002 [ Context 'ext-did-0002' created by 'pbx_config' ] '[REDACTED]' => 1. Set(__FROM_DID=${EXTEN}) [pbx_config] 2. ExecIf($[ "${CALLERID(name)}" = "" ] ?Set(CALLERID(name)=${CALLERID(num)})) [pbx_config] 3. Set(__CALLINGPRES_SV=${CALLERPRES()}) [pbx_config] 4. Set(CALLERPRES()=allowed_not_screened) [pbx_config] 5. Set(_RGPREFIX=M: ) [pbx_config] 6. Set(CALLERID(name)=${RGPREFIX}${CALLERID(name)}) [pbx_config] 7. Set(FAX_DEST=ext-faxt^9999^1) [pbx_config] 8. Answer() [pbx_config] 9. Wait(4) [pbx_config] [dest-ext] 10. Goto(ext-group,600,1) [pbx_config] 'fax' => 1. Goto(${CUT(FAX_DEST,^,1)},${CUT(FAX_DEST,^,2)},${CUT(FAX_DEST,^,3)}) [pbx_config] Include => 'ext-did-0002-custom' [pbx_config] -= 7 extensions (39 priorities) in 1 context. =- BTW, adding a fax extension right on top (in from-trunk) doesn't help | ||
Comments: | By: Paul Belanger (pabelanger) 2010-11-12 07:12:23.000-0600 Attach a debug log (see below) plus your extensions.conf. --- We require a complete debug log to help triage the issue. This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information By: mbrevda (lazytt) 2010-11-14 00:34:06.000-0600 debug log attached By: Jeremy Kister (jkister) 2010-11-14 00:52:24.000-0600 I also run into this issue; I posted on asterisk-users and asterisk-dev on 2010.11.13 I upgraded from a perfectly working 1.6.2 asterisk installation (including fax via app_fax_digium) to 1.8.0 -- and fax functionality has broken. When a fax caller connects, asterisk detects the CNG, logs a message about switching to the fax extension, but then hangs up the call. i have: exten => fax,1,NoOp( got to fax extension ) exten => fax,n,Goto(fax,rx,1) I never receive the noop message. i've captured with: core set verbose 10 core set debug 10 fax set debug on sip set debug peer vgw1 (vgw1 is my cisco 1760 ata) http://jeremy.kister.net/tmp/fax/console.txt http://jeremy.kister.net/tmp/fax/messages.txt http://jeremy.kister.net/tmp/fax/sip.txt By: Jeremy Kister (jkister) 2010-11-14 00:54:02.000-0600 sending the caller directly to ReceiveFax does work as expected; it's just the redirecting process that is broken. By: Paul Belanger (pabelanger) 2010-11-14 07:50:12.000-0600 what is the results of: *CLI> dialplan show fax@from-trunk Also, upload a sample extensions.conf which reproduces the issue. By: Jeremy Kister (jkister) 2010-11-14 10:51:59.000-0600 the most concise extensions.conf that reproduces it is: [incoming] exten => s,1,Answer exten => s,n,Background(local/main) exten => s,n,WaitExten(10) exten => _XX,1,Dial(SIP/1${EXTEN}) exten => fax,1,NoOp( fax extension called ) By: Paul Belanger (pabelanger) 2010-11-14 21:17:49.000-0600 What version of 1.6.2 are you using? By: Jeremy Kister (jkister) 2010-11-14 21:35:29.000-0600 nothing about 1.6.2 is important except that fax was working when i was on 1.6.2.14. the problem is with 1.8.0. By: Paul Belanger (pabelanger) 2010-11-14 22:59:09.000-0600 Odd, I must be doing something wrong on my side. I cannot even get it working under 1.6.2. By: Paul Belanger (pabelanger) 2010-11-14 23:01:50.000-0600 I've also created an automated test located at: http://svn.asterisk.org/svn/testsuite/asterisk/team/pabelanger/faxdetect/ By: mbrevda (lazytt) 2010-11-14 23:39:32.000-0600 As per the original ticket details, the issue is with 1.8.0 - the same dialplan works fine on 1.4/1.6.x. What are your test results? By: Jeremy Kister (jkister) 2010-11-15 09:41:46.000-0600 getting fax to work on 1.6.2 is rather easy. make sure you /don't/ have app_fax loaded and /do/ have res_fax and res_fax_(spandsp|digium) loaded in the sip.conf general, make sure you have faxdetect=yes & t38pt_udptl = yes im near sure that's all you need. By: konstk (konstk) 2010-11-18 08:19:56.000-0600 i had the same issue, it was same problem as in 0018185 solved with the same patch. By: Jeremy Kister (jkister) 2010-11-18 08:32:31.000-0600 the patch in 0018185 has solved the fax transfer issue in my case for asterisk 1.8.0 By: Digium Subversion (svnbot) 2010-11-22 12:46:42.000-0600 Repository: asterisk Revision: 295790 U branches/1.4/apps/app_macro.c U branches/1.4/include/asterisk/channel.h U branches/1.4/include/asterisk/frame.h U branches/1.4/main/channel.c U branches/1.4/main/pbx.c ------------------------------------------------------------------------ r295790 | rmudgett | 2010-11-22 12:46:27 -0600 (Mon, 22 Nov 2010) | 46 lines The channel redirect function (CLI or AMI) hangs up the call instead of redirecting the call. To recreate the problem: 1) Party A calls Party B 2) Invoke CLI "channel redirect" command to redirect channel call leg associated with A. 3) All associated channels are hung up. Note that if the CLI command were done on the channel call leg associated with B it works. This regression was a result of the fix for issue ASTERISK-15731 (https://reviewboard.asterisk.org/r/740/). The regression affects all features that use an async goto to execute the dialplan because of an external event: Channel redirect, AMI redirect, SIP REFER, and FAX detection. The struct ast_channel._softhangup code is a mess. The variable is used for several purposes that do not necessarily result in the call being hung up. I have added doxygen comments to describe how the various _softhangup bits are used. I have corrected all the places where the variable was tested in a non-bit oriented manner. The primary fix is the new AST_CONTROL_END_OF_Q frame. It acts as a weak hangup request so the soft hangup requests that do not normally result in a hangup do not hangup. JIRA SWP-2470 JIRA SWP-2489 (closes issue ASTERISK-16838) Reported by: SantaFox (closes issue ASTERISK-16847) Reported by: kwemheuer (closes issue ASTERISK-16873) Reported by: zahir_koradia (closes issue ASTERISK-16891) Reported by: vmarrone (closes issue ASTERISK-16950) Reported by: mbrevda (closes issue ASTERISK-16972) Reported by: nerbos Review: https://reviewboard.asterisk.org/r/1013/ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=295790 By: Digium Subversion (svnbot) 2010-11-22 13:28:36.000-0600 Repository: asterisk Revision: 295843 _U branches/1.6.2/ U branches/1.6.2/apps/app_macro.c U branches/1.6.2/include/asterisk/channel.h U branches/1.6.2/include/asterisk/frame.h U branches/1.6.2/main/channel.c U branches/1.6.2/main/pbx.c ------------------------------------------------------------------------ r295843 | rmudgett | 2010-11-22 13:28:27 -0600 (Mon, 22 Nov 2010) | 53 lines Merged revisions 295790 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r295790 | rmudgett | 2010-11-22 12:46:26 -0600 (Mon, 22 Nov 2010) | 46 lines The channel redirect function (CLI or AMI) hangs up the call instead of redirecting the call. To recreate the problem: 1) Party A calls Party B 2) Invoke CLI "channel redirect" command to redirect channel call leg associated with A. 3) All associated channels are hung up. Note that if the CLI command were done on the channel call leg associated with B it works. This regression was a result of the fix for issue ASTERISK-15731 (https://reviewboard.asterisk.org/r/740/). The regression affects all features that use an async goto to execute the dialplan because of an external event: Channel redirect, AMI redirect, SIP REFER, and FAX detection. The struct ast_channel._softhangup code is a mess. The variable is used for several purposes that do not necessarily result in the call being hung up. I have added doxygen comments to describe how the various _softhangup bits are used. I have corrected all the places where the variable was tested in a non-bit oriented manner. The primary fix is the new AST_CONTROL_END_OF_Q frame. It acts as a weak hangup request so the soft hangup requests that do not normally result in a hangup do not hangup. JIRA SWP-2470 JIRA SWP-2489 (closes issue ASTERISK-16838) Reported by: SantaFox (closes issue ASTERISK-16847) Reported by: kwemheuer (closes issue ASTERISK-16873) Reported by: zahir_koradia (closes issue ASTERISK-16891) Reported by: vmarrone (closes issue ASTERISK-16950) Reported by: mbrevda (closes issue ASTERISK-16972) Reported by: nerbos Review: https://reviewboard.asterisk.org/r/1013/ ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=295843 By: Digium Subversion (svnbot) 2010-11-22 13:36:26.000-0600 Repository: asterisk Revision: 295866 _U branches/1.8/ U branches/1.8/apps/app_macro.c U branches/1.8/include/asterisk/channel.h U branches/1.8/include/asterisk/frame.h U branches/1.8/main/channel.c U branches/1.8/main/pbx.c ------------------------------------------------------------------------ r295866 | rmudgett | 2010-11-22 13:36:11 -0600 (Mon, 22 Nov 2010) | 60 lines Merged revisions 295843 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.6.2 ................ r295843 | rmudgett | 2010-11-22 13:28:23 -0600 (Mon, 22 Nov 2010) | 53 lines Merged revisions 295790 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r295790 | rmudgett | 2010-11-22 12:46:26 -0600 (Mon, 22 Nov 2010) | 46 lines The channel redirect function (CLI or AMI) hangs up the call instead of redirecting the call. To recreate the problem: 1) Party A calls Party B 2) Invoke CLI "channel redirect" command to redirect channel call leg associated with A. 3) All associated channels are hung up. Note that if the CLI command were done on the channel call leg associated with B it works. This regression was a result of the fix for issue ASTERISK-15731 (https://reviewboard.asterisk.org/r/740/). The regression affects all features that use an async goto to execute the dialplan because of an external event: Channel redirect, AMI redirect, SIP REFER, and FAX detection. The struct ast_channel._softhangup code is a mess. The variable is used for several purposes that do not necessarily result in the call being hung up. I have added doxygen comments to describe how the various _softhangup bits are used. I have corrected all the places where the variable was tested in a non-bit oriented manner. The primary fix is the new AST_CONTROL_END_OF_Q frame. It acts as a weak hangup request so the soft hangup requests that do not normally result in a hangup do not hangup. JIRA SWP-2470 JIRA SWP-2489 (closes issue ASTERISK-16838) Reported by: SantaFox (closes issue ASTERISK-16847) Reported by: kwemheuer (closes issue ASTERISK-16873) Reported by: zahir_koradia (closes issue ASTERISK-16891) Reported by: vmarrone (closes issue ASTERISK-16950) Reported by: mbrevda (closes issue ASTERISK-16972) Reported by: nerbos Review: https://reviewboard.asterisk.org/r/1013/ ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=295866 By: Digium Subversion (svnbot) 2010-11-22 13:42:13.000-0600 Repository: asterisk Revision: 295867 _U trunk/ U trunk/apps/app_macro.c U trunk/include/asterisk/channel.h U trunk/include/asterisk/frame.h U trunk/main/channel.c U trunk/main/pbx.c ------------------------------------------------------------------------ r295867 | rmudgett | 2010-11-22 13:42:03 -0600 (Mon, 22 Nov 2010) | 67 lines Merged revisions 295866 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.8 ................ r295866 | rmudgett | 2010-11-22 13:36:10 -0600 (Mon, 22 Nov 2010) | 60 lines Merged revisions 295843 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.6.2 ................ r295843 | rmudgett | 2010-11-22 13:28:23 -0600 (Mon, 22 Nov 2010) | 53 lines Merged revisions 295790 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r295790 | rmudgett | 2010-11-22 12:46:26 -0600 (Mon, 22 Nov 2010) | 46 lines The channel redirect function (CLI or AMI) hangs up the call instead of redirecting the call. To recreate the problem: 1) Party A calls Party B 2) Invoke CLI "channel redirect" command to redirect channel call leg associated with A. 3) All associated channels are hung up. Note that if the CLI command were done on the channel call leg associated with B it works. This regression was a result of the fix for issue ASTERISK-15731 (https://reviewboard.asterisk.org/r/740/). The regression affects all features that use an async goto to execute the dialplan because of an external event: Channel redirect, AMI redirect, SIP REFER, and FAX detection. The struct ast_channel._softhangup code is a mess. The variable is used for several purposes that do not necessarily result in the call being hung up. I have added doxygen comments to describe how the various _softhangup bits are used. I have corrected all the places where the variable was tested in a non-bit oriented manner. The primary fix is the new AST_CONTROL_END_OF_Q frame. It acts as a weak hangup request so the soft hangup requests that do not normally result in a hangup do not hangup. JIRA SWP-2470 JIRA SWP-2489 (closes issue ASTERISK-16838) Reported by: SantaFox (closes issue ASTERISK-16847) Reported by: kwemheuer (closes issue ASTERISK-16873) Reported by: zahir_koradia (closes issue ASTERISK-16891) Reported by: vmarrone (closes issue ASTERISK-16950) Reported by: mbrevda (closes issue ASTERISK-16972) Reported by: nerbos Review: https://reviewboard.asterisk.org/r/1013/ ........ ................ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=295867 |